On Thu, Sep 12, 2024 at 5:08 PM Edgecombe, Rick P <rick.p.edgecombe@xxxxxxxxx> wrote: > > KVM can have a TDX-specific version of KVM_GET_SUPPORTED_CPUID, so > > that we can keep a variant of the "get supported bits and pass them > > to KVM_SET_CPUID2" logic, but that's it. > > Can you clarify what you mean here when you say TDX-specific version of > KVM_GET_SUPPORTED_CPUID? > > We have two things kind of like that implemented in this series: > 1. KVM_TDX_GET_CPUID, which returns the CPUID bits actually set in the TD > 2. KVM_TDX_CAPABILITIES, which returns CPUID bits that TDX module allows full > control over (i.e. what we have been calling directly configurable CPUID bits) > > KVM_TDX_GET_CPUID->KVM_SET_CPUID2 kind of works like > KVM_GET_SUPPORTED_CPUID->KVM_SET_CPUID2, so I think that is what you mean, but > just want to confirm. Yes, that's correct. > We can't get the needed information (fixed bits, etc) to create a TDX > KVM_GET_SUPPORTED_CPUID today from the TDX module, so we would have to encode it > into KVM. This was NAKed by Sean at some point. We have started looking into > exposing the needed info in the TDX module, but it is just starting. I think a bare minimum of this API is needed (adding HYPERVISOR, and masking TDX-supported features against what KVM supports). It's too much of a fundamental step in KVM's configuration API. I am not sure if there are other fixed-1 bits than HYPERVISOR as of today. But in any case, if the TDX module breaks it unilaterally by adding more fixed-1 bits, that's a problem for Intel not for KVM. On the other hand is KVM_TDX_CAPABILITIES even needed? If userspace can replace that with hardcoded logic or info from the infamous JSON file, that would work. Paolo
