Received-SPF: pass (google.com: domain of linux-kernel+bounces-157384-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Wed, 24 Apr 2024 10:23:30 -0700
In-Reply-To: <26073e608fc450c6c0dcfe1f5cb1590f14c71e96.camel@intel.com>
Precedence: bulk
Mime-Version: 1.0
References: <cover.1711035400.git.reinette.chatre@intel.com>
 <6fae9b07de98d7f56b903031be4490490042ff90.camel@intel.com>
 <Ziku9m_1hQhJgm_m@google.com> <26073e608fc450c6c0dcfe1f5cb1590f14c71e96.camel@intel.com>
Message-ID: <ZilAEhUS-mmgjBK8@google.com>
Subject: Re: [PATCH V4 0/4] KVM: x86: Make bus clock frequency for vAPIC timer configurable
From: Sean Christopherson <seanjc@google.com>
To: Rick P Edgecombe <rick.p.edgecombe@intel.com>
Cc: "jmattson@google.com" <jmattson@google.com>, Chao Gao <chao.gao@intel.com>, 
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "vkuznets@redhat.com" <vkuznets@redhat.com>, 
	Vishal Annapurve <vannapurve@google.com>, Xiaoyao Li <xiaoyao.li@intel.com>, 
	Reinette Chatre <reinette.chatre@intel.com>, Erdem Aktas <erdemaktas@google.com>, 
	"pbonzini@redhat.com" <pbonzini@redhat.com>, "mlevitsk@redhat.com" <mlevitsk@redhat.com>, 
	Isaku Yamahata <isaku.yamahata@intel.com>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 24, 2024, Rick P Edgecombe wrote:
> On Wed, 2024-04-24 at 09:13 -0700, Sean Christopherson wrote:
> > On Tue, Apr 16, 2024, Rick P Edgecombe wrote:
> > > On Thu, 2024-03-21 at 09:37 -0700, Reinette Chatre wrote:
> > > >=20
> > > > Summary
> > > > -------
> > > > Add KVM_CAP_X86_APIC_BUS_FREQUENCY capability to configure the APIC
> > > > bus clock frequency for APIC timer emulation.
> > > > Allow KVM_ENABLE_CAPABILITY(KVM_CAP_X86_APIC_BUS_FREQUENCY) to set =
the
> > > > frequency in nanoseconds. When using this capability, the user spac=
e
> > > > VMM should configure CPUID leaf 0x15 to advertise the frequency.
> > >=20
> > > Looks good to me and...
> > > Tested-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
> > >=20
> > > The only thing missing is actually integrating it into TDX qemu patch=
es and
> > > testing the resulting TD. I think we are making a fair assumption tha=
t the
> > > problem should be resolved based on the analysis, but we have not act=
ually
> > > tested that part. Is that right?
> >=20
> > Please tell me that Rick is wrong, and that this actually has been test=
ed with
> > a TDX guest.=C2=A0 I don't care _who_ tested it, or with what VMM it ha=
s been
> > tested, but _someone_ needs to verify that this actually fixes the TDX =
issue.
>=20
> It is in the process of getting a TDX test developed (or rather updated).
> Agreed, it requires verification that it fixes the original TDX issue. Th=
at is
> why I raised it.
>=20
> Reinette was working on this internally and some iterations were happenin=
g, but
> we are trying to work on the public list as much as possible per your ear=
lier
> comments. So that is why she posted it.

I have no problem posting "early", but Documentation/process/maintainer-kvm=
-x86.rst
clearly states under Testing that:

  If you can't fully test a change, e.g. due to lack of hardware, clearly s=
tate
  what level of testing you were able to do, e.g. in the cover letter.

I was assuming that this was actually *fully* tested, because nothing sugge=
sts
otherwise.  And _that_ is a problem, e.g. I was planning on applying this s=
eries
for 6.10, which would have made for quite the mess if it turns out that thi=
s
doesn't actually solve the TDX problem.

> There was at least some level of TDX integration in the past. I'm not sur=
e what
> exactly was tested, but we are going to re-verify it with the latest ever=
ything.

Honest question, is it a big lift to re-test the QEMU+KVM TDX changes, e.g.=
 to
verify this new capability actually does what we hope it does?  If testing =
is a
big lift, what are the pain points?  Or perhaps a better question is, is th=
ere
anything we (both upstream people, and end users like Google) can do to mak=
e
re-testing less awful?