On Tue, Apr 09, 2024, Rick P Edgecombe wrote: > On Tue, 2024-04-09 at 08:23 -0700, Sean Christopherson wrote: > > > Right, I thought I heard this on the call, and to use the upper bits of > > > that leaf for GPAW. What has changed since then is a little more learning > > > on the TDX module behavior around CPUID bits. > > > > > > The runtime API doesn't provide what the fixed values actually are, but > > > per the TDX module folks, which bits are fixed and what the values are > > > could change without an opt-in. > > > > Change when? While the module is running? Between modules? > > Between modules. They are fixed for a specific TDX module version. But the TDX > module could change. > > Ah! Maybe there is confusion about where the JSON file is coming from. It is > *not* coming from the TDX module, it is coming from the Intel site that has the > documentation to download. It another form of documentation. I know. > Haha, if this is the confusion, I see why you reacted that way to "JSON". > That would be quite the curious choice for a TDX module API. > > So it is easy to convert it to a C struct and embed it in KVM. It's just not > that useful because it will not necessarily be valid for future TDX modules. No, I don't want to embed anything in KVM, that's the exact same as hardcoding crud into KVM, which is what I want to avoid. I want to be able to roll out a new TDX module with any kernel changes, and I want userspace to be able to assert that, for a given TDX module, the effective guest CPUID configuration aligns with userspace's desired the vCPU model, i.e. that the value of fixed bits match up with the guest CPUID that userspace wants to define. Maybe that just means converting the JSON file into some binary format that the kernel can already parse. But I want Intel to commit to providing that metadata along with every TDX module.
