Re: [ANNOUNCE] PUCK Notes - 2024.04.03 - TDX Upstreaming Strategy

["Edgecombe, Rick P" <rick.p.edgecombe@intel.com>]

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.