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

[Binbin Wu <binbin.wu@linux.intel.com>]

On 9/2/2026 11:09 PM, Xiaoyao Li wrote:
> On 9/2/2026 8:33 AM, Binbin Wu wrote:
>>>> +static void __init tdx_initialize_cpu_cfg_caps(void)
>>>> +{
>>>> +    tdx_cpu_cfg_cap_init(CPUID_1_ECX,
>>>> +        TDX_CFG_EXTRA_F(MWAIT),
>>>> +        TDX_CFG_F(TSC_DEADLINE_TIMER),
>>>> +        TDX_CFG_F(AVX),
>>>> +        TDX_CFG_F(F16C),
>>>> +    );
>>> TDX 1.5.24 on SPR report configurable bits of CPUID_1_ECX as
>>> 0x31044988, which have
>>>
>>> - bit 3        MWAIT
>>> - bit 7        EST
>>> - bit 8        TM2
>>> - bit 11    SDBG
>>> - bit 14    XTPR
>>> - bit 18    DCA
>>> - bit 24    TSC_DEADLINE_TIMER
>>> - bit 28    AVX
>>> - bit 29    F16C
>>>
>>> but EST/TM2/SDBG/XTPR/DCA are not list here. I guess the reason is kvm_cpu_cap[] doesn't support it. If so, it seems to guard twice:
>>> 1. mentally/manually check if it a feature is supported in kvm_cpu_caps[]
>>>
>>> 2. kvm_cpu_caps guarding in tdx_cpu_cfg_cap_init().
>>>
>>> I think 1) is not necessary, we can rely on 2)
>> In general, if a feature is not supported by the common KVM CPU caps, 
> 
> For kvm-intel.ko, kvm_cpu_caps[] just means the supported CPUID features
> for VMX VMs. Treat it as the common KVM CPU caps is a bit arguable.
> 
>> I prefer not
>> to add it to the list to save a few lines of code, which probably is dead code,
> 
> I don't think it's dead code. It shows that these features are
> virtualizable to TDs from the POV. of TDX.

It depends on whether KVM allows userspace to set features for TDs that are not support
for non-TDX VMs (,except for a few exceptions).

In this version, TDX_CFG_F() already check against kvm_cpu_caps[], if these features
are not in kvm_cpu_caps[], it will not be exposed to userspace anyway.

> 
> In the end, they might be disallowed to be configured to TDs because KVM
> doesn't allow them for VMX VMs. This is also the point I want to discuss.
> Do we really want to make such restriction that KVM cannot enable/allow a
> feature for TDs unless KVM first enables/allows it for VMX VMs? What's
> reason behind it?

Sean mentioned it that "generally speaking, KVM shouldn't allow features
that KVM doesn't support for non-TDX VMs" in
https://lore.kernel.org/kvm/aj1fi_0SBxMK5WOB@google.com/

> 
>> unless people find it too confusing.
>> I can add a comment to clarify this.
>>
>>> BTW, this seems also breaks the current userspace after this series.
>>> - Before, EST/TM2/SDBG/XTPR/DCA are allowed to be exposed to TD
>>> - After, they are not.
>> This does change the values returned by KVM_TDX_CAPABILITIES. However, my
>> understanding is that userspace is generally expected to only configure
>> features supported by both KVM and TDX, i.e. except for the features initialized
>> via TDX_CFG_EXTRA_F(), userspace is not expected to configure features not advertised
>> by kvm_cpu_caps[].
>> I can call this out in the changelog, and maybe also the doc for KVM_TDX_CAPABILITIES.
> 
> yeah. This changes KVM's behavior and we definitely need to call it out,
> and provide justification.
> 
>>> If we cares CORE_CAPABILITIES in patch 2, why EST/TM2/SDBG/XTPR/DCA don't matter?
>> Because CORE_CAPABILITIES was previously defined as fixed-1 in some old spec and
>> the QEMU marks it as fixed1. EST/TM2/SDBG/XTPR/DCA are not the case.
> 
> I see. You added patch 2 because without it QEMU breaks. While for
> EST/TM2/SDBG/XTPR/DCA, QEMU doesn't break after they are turned to
> non-configurable. QEMU cannot represent all the userspace VMM. It still has
> the potential to breaks other userspace VMMs.

I think the risk is pretty low.
I am not sure if Sean could provide some insight about this in google's userspace
VMM.