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

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

On 9/23/2026 8:45 AM, Edgecombe, Rick P wrote:
> On Wed, 2026-09-23 at 08:14 +0800, Binbin Wu wrote:
>>> Sorry, I'm not following this logic exactly. The guest can control it's own
>>> view
>>> of CPUID. Why do we need to filter the host setting them via direct
>>> configuration, just because the guest can change it's view to exclude them?
>>
>>
>> These feature neither supported by the TDX module nor supported by the KVM.
>> If the guest enabled the #VE reduction, the access to the related MSRs will
>> cause #GP. If the guest doesn't enabled the #VE redcution, #VE cannot be
>> supported by KVM since the related MSRs are not support by KVM.
>>
>> So the guest cannot use these features anyway.
> 
> 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.

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