On Thu, 2024-09-12 at 17:37 +0200, Paolo Bonzini wrote: > Yes, that's correct. Thanks. > > > 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. Ok so we want KVM_TDX_CAPABILITIES to filter bits, but not KVM_TDX_GET_CPUID. > > 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. The directly configurable CPUID bits will grow over time. So if we don't expose the supported ones, userspace will have to guess which ones it can set at that point. But as long as the list doesn't shrink we could encode the directly configurable data in userspace for now, then add an API later when the list of bits grows. If the API is not present, userspace can assume it's only the original list.
