Re: [RFC PATCH v2 1/4] KVM: x86: TDX: Track supported configurable CPUID bits

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

On 6/30/2026 8:37 AM, Sean Christopherson wrote:
> On Mon, Jun 29, 2026, Binbin Wu wrote:
>> On 6/26/2026 1:04 AM, Sean Christopherson wrote:
>>> On Thu, Jun 04, 2026, Binbin Wu wrote:
>>> CPUID.0x1E is a bit different because it's kinda sorta a feature?  That one is
>>> probably worth restricting, but again that's easy to do in a case-statement.
>>
>> Only CPUID.0x1E.EAX has TDX directly configurable bits currently, no special
>> handling needed for the rest of CPUID.0x1E.
> 
> But isn't the whole point to guard against TDX Modules gaining support for features
> KVM doesn't know about?  What happens if hardware extends into CPUID.0x1E.ECX,
> and the TDX Module follows suit?

I meant for CPUID.0x1E, KVM only allows the known TDX configurable CPUID bits, i.e. 
AMX_FP8, AMX_TF32, AMX_AVX512, and AMX_MOVRS in CPUID.0x1E.EAX, which will be
initialized in kvm_tdx_cpu_caps[]. 
For others, it's not allowed via KVM_TDX_INIT_VM. If there is a unknown feature
bit, it will be rejected.
 > 
> I guess that applies to all the feature leaves?

I think the rules could be:
1) if a leaf/sub-leaf/register we are sure that it will never be extended for feature
   bits, as you mentioned, e.g. CPUID.0x1.E{A,B}X, CPUID 0x4, 0x18, and 0x1F, we handle
   them in case-statement runtime.

2) If a leaf/sub-leaf/register that could be extended for feature bits or already
   is used for feature bits, the kvm_tdx_cpu_caps[] holds the supported direct
   configurable bits. The userspace CPUID configuration input in KVM_TDX_INIT_VM is
   validated against kvm_tdx_cpu_caps[]. Any unknown feature bit is not allowed.