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

[Edgecombe, Rick P]

On Thu, 2026-09-17 at 15:25 +0800, Binbin Wu wrote:
> Add tdx_cpu_cfg_caps[] to track the subset of TDX directly configurable
> CPUID feature bits that KVM supports, and build the masks during TDX
> hardware setup via tdx_initialize_cpu_cfg_caps().
> 
> The TDX module reports the CPUID bits that the VMM can directly configure
> for a TD, but KVM cannot blindly expose all reported bits to userspace.
> Certain features imply additional architectural state, e.g. one or more
> MSRs, that KVM must explicitly manage across host/guest transitions to
> prevent host state corruption.  The existing hardcoded denylist cannot
> account for new host state clobbering features introduced by future TDX
> modules.
> 
> Except for a few fixed-1 bits required for basic TDX support, host state
> clobbering features are either directly configurable or gated by TD
> ATTRIBUTES/XFAM, which KVM already validates.  Tracking only the directly
> configurable bits to build an allowlist is therefore sufficient.
> 
> Organize tdx_cpu_cfg_caps[] following kvm_cpu_caps[] so that the masks can
> be built with similar feature-name based initializers.  Directly
> configurable non-feature bits will be handled separately.
> 
> The allowlist is prepared to be consumed by later patches to filter
> KVM_TDX_CAPABILITIES and to reject unsupported CPUID input to
> KVM_TDX_INIT_VM, so that newly introduced TDX directly configurable CPUID
> feature bits stay hidden from userspace until KVM explicitly opts in.
> 
> By default, intersect the allowlist with kvm_cpu_caps[] via TDX_CFG_F().
> Requiring support for non-TDX VMs avoids committing to TDX-specific
> behavior before general KVM support is established, and respects KVM's
> logic around disabling certain features, since the reasons for disabling
> them could apply to TDX as well.  Allow exceptions through
> TDX_CFG_EXTRA_F() only with sufficient justification.
> 
> Add comments as placeholders for HLE, RTM, WAITPKG and FRED, which KVM
> doesn't support for TDX yet.
> 
> Allow MWAIT, XTPR, and HT through TDX_CFG_EXTRA_F(), as these bits are
> not advertised in kvm_cpu_caps[].  The remaining directly configurable
> feature bits outside kvm_cpu_caps[] are left out of the allowlist:
> 
>   - Features forced to zero when #VE is reduced,
> 

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?

>  or lacking KVM support
>     for the associated MSRs: EST, TM2, SDBG, DCA, ACPI, ACC (TM), RDT_A,
>     RDT_M, TME, PCONFIG, and CORE_CAPABILITIES.  Handle CORE_CAPABILITIES
>     in a subsequent patch.
> 
>   - Features tied to IA32_MISC_ENABLE bits that a TD cannot set when
>     TDCS.TD_CTLS.REDUCE_VE is set: CID and PBE.
> 
>   - Features that can clobber host state and lack KVM support for TDX:
>     FRED.

I think we can't say this quite yet. The arch isn't finalized.

> 
>   - Unsupported features: PREFETCHWT1 (Xeon Phi only), PSN (absent from
>     TDX-capable CPUs), AMX-TRANSPOSE (never implemented on an Intel
>     platform), and RAO_INT (defined only for future processors).
> 
> Filtering KVM_TDX_CAPABILITIES in a subsequent patch will intentionally

Nit: "patch" -> "change"

This is drilled into my head working on the tip side. I'm not sure if Sean has
the same allergy though.

> stop advertising the excluded bits as configurable, as the corresponding
> features are unsupported or cannot be properly virtualized.
> 
> Signed-off-by: Binbin Wu <binbin.wu@xxxxxxxxxxxxxxx>

Overall it looks very good to me.