On Fri, Mar 22, 2024 at 07:10:42AM +0000, "Huang, Kai" <kai.huang@xxxxxxxxx> wrote: > On Thu, 2024-03-21 at 23:12 +0000, Edgecombe, Rick P wrote: > > On Mon, 2024-02-26 at 00:27 -0800, isaku.yamahata@xxxxxxxxx wrote: > > > Implement a hook of KVM_SET_CPUID2 for additional consistency check. > > > > > > Intel TDX or AMD SEV has a restriction on the value of cpuid. For > > > example, > > > some values must be the same between all vcpus. Check if the new > > > values > > > are consistent with the old values. The check is light because the > > > cpuid > > > consistency is very model specific and complicated. The user space > > > VMM > > > should set cpuid and MSRs consistently. > > > > I see that this was suggested by Sean, but can you explain the problem > > that this is working around? From the linked thread, it seems like the > > problem is what to do when userspace also calls SET_CPUID after already > > configuring CPUID to the TDX module in the special way. The choices > > discussed included: > > 1. Reject the call > > 2. Check the consistency between the first CPUID configuration and the > > second one. > > > > 1 is a lot simpler, but the reasoning for 2 is because "some KVM code > > paths rely on guest CPUID configuration" it seems. Is this a > > hypothetical or real issue? Which code paths are problematic for > > TDX/SNP? > > There might be use case that TDX guest wants to use some CPUID which > isn't handled by the TDX module but purely by KVM. These (PV) CPUIDs need to be > provided via KVM_SET_CPUID2. > > > Btw, Isaku, I don't understand why you tag the last two patches as RFC and put > them at last. I think I've expressed this before. Per the discussion with > Sean, my understanding is this isn't something optional but the right thing we > should do? > > https://lore.kernel.org/lkml/ZDiGpCkXOcCm074O@xxxxxxxxxx/ Ok, let's remove RFC and reorder this patches. Do you see any issue of the cpuid check logic itself? -- Isaku Yamahata <isaku.yamahata@xxxxxxxxx>
