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: > > > > > > > > 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 space > > > > VMM should configure CPUID leaf 0x15 to advertise the frequency. > > > > > > Looks good to me and... > > > Tested-by: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx> > > > > > > The only thing missing is actually integrating it into TDX qemu patches and > > > testing the resulting TD. I think we are making a fair assumption that the > > > problem should be resolved based on the analysis, but we have not actually > > > tested that part. Is that right? > > > > Please tell me that Rick is wrong, and that this actually has been tested with > > a TDX guest. I don't care _who_ tested it, or with what VMM it has been > > tested, but _someone_ needs to verify that this actually fixes the TDX issue. > > 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. That is > why I raised it. > > Reinette was working on this internally and some iterations were happening, but > we are trying to work on the public list as much as possible per your earlier > 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 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. > 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?
