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

[Xiaoyao Li <xiaoyao.li@intel.com>]

On 9/23/2026 9:17 AM, Binbin Wu wrote:
> On 9/23/2026 9:09 AM, Edgecombe, Rick P wrote:
>> On Wed, 2026-09-23 at 08:57 +0800, Binbin Wu wrote:
>>>> But directly configurable bits don't have any direct conntion to tdcall
>>>> queried bits. Userspace can still set those to whatever it wants regardless
>>>> of the allow list. 
>>>
>>> I didn't quite get this.
>>
>> VE bits don't query the directly configurable bits in any case unless userspace
>> sets it up that way. So they are not involved in the problem we are trying to
>> fix here.
>>
>>>
>>>>
>>>> So the argument is basically there is not expected to be any reason to allow
>>>> them, so save the code in the allow list. It's a "there is no point" reason.
>>>> Makes sense, but I couldn't get that from explanation.
>>>
>>> I think "not just save the code"?
>>> One argument is that if these bits are reported as allowed to userspace and
>>> userspace enabled them during init, and the guest doesn't opt-in the #VE
>>> reduction (KVM doesn't know the real setting), it would cause problem in the
>>> guest.
>>
>> Userspace is allowed to cause problems to the guest. We shouldn't try to prevent
>> it. 
> 
> 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. 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.