Message-ID: <6f476d85cdb9dfdc0893e9eb762dca08f0f5f19b.camel@intel.com>
Date: Wed, 24 Apr 2024 18:10:02 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "seanjc@...gle.com" <seanjc@...gle.com>
CC: "jmattson@...gle.com" <jmattson@...gle.com>, "Gao, Chao"
	<chao.gao@...el.com>, "vkuznets@...hat.com" <vkuznets@...hat.com>,
	"Annapurve, Vishal" <vannapurve@...gle.com>, "Li, Xiaoyao"
	<xiaoyao.li@...el.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "Verma, Vishal L" <vishal.l.verma@...el.com>,
	"Chatre, Reinette" <reinette.chatre@...el.com>, "pbonzini@...hat.com"
	<pbonzini@...hat.com>, "Aktas, Erdem" <erdemaktas@...gle.com>, "Yamahata,
 Isaku" <isaku.yamahata@...el.com>, "mlevitsk@...hat.com"
	<mlevitsk@...hat.com>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>
Subject: Re: [PATCH V4 0/4] KVM: x86: Make bus clock frequency for vAPIC timer
 configurable

+Vishal

On Wed, 2024-04-24 at 10:23 -0700, Sean Christopherson wrote:
> 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
> state
>   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 suggests
> otherwise.  And _that_ is a problem, e.g. I was planning on applying this
> series
> for 6.10, which would have made for quite the mess if it turns out that this
> doesn't actually solve the TDX problem.

Ok, sorry. Will definitely be clear about this in the future. There is a little
bit of chaos on our end right now as new people spin up and we adjust our
working model to be more upstream focused. Thanks for being clear.

Yes, please don't apply until we have the full testing done. It may not be far
away though, per Reinette.

> 
> > There was at least some level of TDX integration in the past. I'm not sure
> > what
> > exactly was tested, but we are going to re-verify it with the latest
> > everything.
> 
> 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 there
> anything we (both upstream people, and end users like Google) can do to make
> re-testing less awful?

I wouldn't say a big lift, but probably more than usual. Most of the testing
challenges come from updating and matching specific, often out of tree
components. We need to have specific OVMF, TDX module, QEMU, KVM core patches,
KVM breakout series, and tests versions that all match.

To wrangle it, automated testing is something we are working on internally right
now. I can't think of anything to ask of upstream specifically. But Vishal
might.

As for Google, the TDX selftests are useful. We need to update them ourselves to
keep up with uAPI changes. We could do a little more co-development on those? As
in, not wait until we post new versions to get updates from Google's side. Just
an idea off the top of my head.

As for the TDX kvm unit tests updates [0]. They have not had much review. I
think we maybe have enough TDX patches to focus on already though.

Long term though, I have been wondering about how to prevent TDX regressions
especially on the MMU pieces. It is one thing to have the TDX setups available
for maintainers, but most normal developers will likely not have access to TDX
HW for a bit. Just a problem without a solution.

[0] https://lore.kernel.org/kvm/20231218072247.2573516-1-qian.wen@intel.com/#t

Powered by blists - more mailing lists