Re: [PATCH v4 1/4] KVM: TDX: Track configurable CPUID bits allowed by KVM

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

On Wed, 2026-09-23 at 19:21 +0800, Xiaoyao Li wrote:
> > But userspace doesn't know these bits are not supported by TDX module and
> > KVM. If KVM report them as supported, and it causes problems, we cannot say
> > it's userspace's fault.
> 
> It sounds like a bug fix to existing KVM behavior.
> 
> Current KVM doesn't allow HLE/RTM/WAITPKG because it might cause bad effect on
> the host. But for those #VE related, though KVM doesn't support virtualizing
> the features, it doesn't cause any harm to the host when KVM allows them to be
> configured to TDs. It only causes problems to TDs.
> 
> For normal VMs, KVM_GET_SUPPORTED_CPUID and other KVM CAPs serve as the
> interface to report to userspace if a feature is support or not. If userspace
> exposes a feature to guest when KVM reports the feature is not supported, and
> it causes problem to guests, we can say it's userspace's fault.

Yes.

>  But for TDX,
> there is not interface to report KVM's support capabilities. After this
> series, KVM_TDX_CAPABILITIES can serve as the interface. So it looks like a
> bug fix to me.

KVM needs to support all the bits that are 1 in the TD. Either directly
configurable or fixed-1 or whatever. Userspace doesn't find out which bits these
are until it does the KVM_TDX_GET_CPUID, at which point it finds out the
"support" in a heavy handed way. So I think userspace does learn everything it
needs already. And as long we don't have new fixed-1 bits, we will avoid KVM
being forced to support things too early.

Except for exposing TD KVM PV bit support, which we already talked about doing
as follow on.