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/
