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

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

On 9/24/2026 10:33 PM, Xiaoyao Li wrote:
> On 9/24/2026 7:41 PM, Binbin Wu wrote:
[...]
>>> For X86_FEATURE_PBE (CPUID.0x1:EDX[31]), it's related to bit 10 of MSR
>>> IA32_MISC_ENABLE. The CPUID is 1 on SPR and EMR. But bit 10 of MSR
>>> IA32_MISC_ENABLE is always 0 and setting bit 10 to 1 fails. It seems though
>>> CPUID.0x1:EDX[31] is set to 1, but it's not related to bit 10 of MSR
>>> IA32_MISC_ENABLE?
>> In the ISE (319433-062, table 1-6), it says:
>>   PBE:
>>   Pending Break Enable. The processor supports the use of the FERR#/PBE# pin
>>   when the processor is in the stop-clock state (STPCLK# is asserted) to signal
>>   the processor that an interrupt is pending and that the processor should
>>   return to normal operation to handle the interrupt. Bit 10 (PBE enable) in the
>>   IA32_MISC_ENABLE MSR enables this capability.
>>
>> TDX module doesn't allow IA32_MISC_ENABLE[10] to be 1 is since it's reserved
>> TDCS.TD_CTLS.REDUCE_VE is set, so my understanding was the CPUID bit should be 0. 
>>
>> It seems bit 10 is phased out in IA32_MISC_ENABLE on modern processors like SPR
>> and EMR, since the bit 10 is reserved in "IA-32 Architectural MSRs" table. But
>> somehow, CPUID still reports PBE as supported.
> 
> yeah. arch/x86/include/asm/msr-index.h divides the bits of MSR IA32_MISC_ENABLE
> into two groups: architectural and model-specific. Bit 10 falls into model-specific.
> 
> Maybe we can ask internally why CPUID still reports 1.
> 
>> I don't know why the CPUID is disconnected with the MSR.
>> But this bit is present on the host, I think we can add it to the allowlist.
> 
> I have opposite opinion. Since 1) this feature is related to hardware processor
> PIN, 2) KVM never advertise it to normal VMs, and 3) no usage in kernel for this
> feature. I think no TD relies on it and don't allow it should be OK.

My consideration was maybe some userspace could set this bit.

But userspace is expected to consult KVM_TDX_CAPABILITIES for the configurable
bits before invoking KVM_TDX_INIT_VM, regardless of this patch series, there is
no risk to break userspace, except for CORE_CAPABILITIES, which is the only special
case as it was defined as fixed-1.

I think there is no need to add XTPR to the allow list either.