Re: [PATCH v3 3/4] KVM: TDX: Filter configurable CPUID bits

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

On 9/3/2026 4:04 PM, Xiaoyao Li wrote:
>> +static u32 tdx_cfg_non_feature_mask(u32 function, u32 index, int reg)
>>  {
>> -	if (has_tsx(entry))
>> -		clear_tsx(entry);
>> +	/*
>> +	 * For a leaf/subleaf/register that will never be repurposed to hold
>> +	 * feature bits, it's safe to return TDX_CPUID_ALL_ALLOWED_MASK, i.e.
>> +	 * leave the TDX module's CPUID config mask intact.
>> +	 */
> 
> I don't think blindly return TDX_CPUID_ALL_ALLOWED_MASK, i.e. all-1s, is a
> good idea. It's just like the current behavior that KVM doesn't gate
> anything and allows userspace to set anything that is allowed by TDX
> module. For example, ...

Sean suggested that "Realistically, CPUID.0x1.E{A,B}X are never going to be
repurposed to hold feature bits, and so generating a mask of allowed bits adds
unnecessary cognitive load and maintenance.  Ditto for CPUID 0x4, 0x18, and 0x1F."
https://lore.kernel.org/kvm/aj1fi_0SBxMK5WOB@google.com/

And I added 0x80000008.EAX as well.

> 
>> +	switch (function) {
>> +	case 1:
>> +		if (reg == CPUID_EAX || reg == CPUID_EBX)
>> +			return TDX_CPUID_ALL_ALLOWED_MASK;
> 
> ... TDX module returns 0x0fff3fff for CPUID.1.EAX currently. If KVM makes
> the mask as all-1s, then if in the future the reserved field [15:14] and
> [31:28] are defined for new things and new TDX module starts to report them
> as configurable, then the bits will be configurable by userspace on old
> kernels while we don't know if its safe for KVM/kernel.
> 
>> +		return 0;
>> +	case 4:
>> +	case 0x18:
>> +	case 0x1f:
>> +		return TDX_CPUID_ALL_ALLOWED_MASK;
>> +	case 0x24:
>> +		if (index == 0 && reg == CPUID_EBX)
>> +			return GENMASK_U32(7, 0);
>> +		return 0;
>> +	case 0x80000008:
>> +		if (reg == CPUID_EAX)
>> +			return TDX_CPUID_ALL_ALLOWED_MASK;
>> +		return 0;
>> +	default:
>> +		return 0;
>> +	}
>> +}
>