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

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

On 9/24/2026 7:41 PM, Binbin Wu wrote:
...
>>>> As for "features forced to zero when #VE is reduced", do you mean when TDX
>>>> module supports "#VE reduction" feature, the features becomes fixed0? or when
>>>> guest enables "reduce #VE", the guest see a 0 value even though the feature is
>>>> still configurable to host userspace and host userspace configure it to 1?
>>>
>>>
>>> #VE is reduced means the guest reduced the related #VE, i.e. TDCS.TD_CTRL.REDUCE_VE
>>> is 1 and the related bit in TDCS.FEATURE_PARAVIRT_CTRL is 0.
>>
>> I think "features forced to zero when #VE is reduced" doesn't matter at all
>> here.
> 
> I think it still matters.
> 
> If there is a feature that is virtualized by the TDX module itself, but KVM doesn't
> support it for non-TDX VMs, I think it should be allowed.
> 
> These features can't be added to the allow list because neither TDX module nor
> KVM do the virtualization for them.

... <snip>
>> I think all the bits that are directly configurable but out of kvm_cpu_caps[]
>> and not supported by KVM fall into the last category. You can just list all of
>> them instead of my "for example".
> 
> As I mentioned above, if there is a feature that is virtualized by the TDX module itself,
> but KVM doesn't support it for non-TDX VMs, it should be allowed. Although I don't have
> a concrete example. I think we still need to mention #VE reduction to some degree, but
> let me see how to simplify the description.

(This reply only concentrates on the discussion of "if there is a feature that
is virtualized by the TDX module itself")

If you are talking about the features related to #VE, I think there is no.
Because if TDX module itself can virtualize the feature, then it shouldn't be
#VE at all. #VE means it needs para-virt support from host VMM.

If you are talking about the features unrelated to #VE. I think it's just the
case I argued for in previous v3, that we can support a feature for TDX first
before non-TDX VMs. I think we all agreed that such case can happen and we
decided to support such case when there is a real case.