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

[Binbin Wu]

On 9/24/2026 9:55 PM, Xiaoyao Li wrote:
> 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.

I was thinking a hypothetical scenario, but this #VE reduction thing is already
complicated enough, I shouldn't not muddy the waters with a hypothetical scenario.

Anyway, I will try to simplify the commit message without mentioning #VE reduction.

> 
> 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.

Yep.