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. 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. > > > This begged the questions for me of what exactly KVM should expect of TDX > > module backwards compatibility and what SW is expected to actually do with > > that JSON file. I'm still trying to track that down. > > There is nothing to track down, we damn well state what KVM's requirements > are, > and the TDX folks make it so. I'm on the same page. > > I don't want JSON. I want a data payload that is easily consumable in C code, > which contains (a) the bits that are fixed and (b) their values. If a value > can > change at runtime, it's not fixed. Right. The fixed values have to come in a reasonable format from the TDX module at runtime, or require an opt-in for any CPUID bits to change in future TDX modules. > > The only question is, how do we document/define/structure KVM's uAPI so that > _if_ > the TDX module breaks backwards compatibility by mucking with fixed bits, then > it's Intel's problem, not KVM's problem. If we can't trust it at all, then we can always disable it if it behaves badly. I think everyone would like to avoid this. Yes, if we have a better idea of how it would change, we can try to avoid that scenario with API design.
