[PATCH v5 0/5] KVM: TDX: Validate directly configurable CPUID bits

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

The TDX module reports a set of CPUID bits that the VMM can directly
configure for a TD, but KVM cannot blindly expose all module-supported
bits to userspace.  Certain features imply additional architectural state
(such as one or more MSRs) that KVM must explicitly manage across
host/guest transitions to prevent host state corruption.

Today, KVM hardcodes a denylist to filter out host state clobbering
features that KVM doesn't support.  However, a denylist doesn't scale as
the TDX module evolves, i.e. host state clobbering features added by a
future TDX module are not covered by the denylist, and userspace could
enable a feature that KVM doesn't support.

This series builds an allowlist for directly configurable CPUID bits, and
filters and validates userspace input against it, so that newly introduced
TDX directly configurable CPUID feature bits can only be enabled by
userspace after KVM explicitly opts in.  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.  KVM already
validates ATTRIBUTES/XFAM, so the allowlist only needs to cover directly
configurable bits.

Patch 1 is a standalone fix for the existing denylist check, which uses
the index of the matched userspace entry instead of the subleaf reported
by the TDX module, i.e. userspace can bypass the HLE/RTM/WAITPKG check.
It is tagged for stable so that it can be backported independently of
the rest of the series.

Patches 2-5 build the allowlist, add CORE_CAPABILITIES to it, filter
KVM_TDX_CAPABILITIES, and validate the CPUID input of KVM_TDX_INIT_VM.
The last two patches are user-visible changes, which are now called out
in their changelogs, along with why existing userspace and guests are not
expected to be affected.

For this version, I'm hoping to continue to collect some RBs and Acks.
The key discussions from v3/v4 [1] are summarized below.  Note, FRED KVM
support is in progress upstream [2], and no TDX module with FRED support
exists yet, so there is no immediate issue.  But it would be nice to get
this series merged sooner rather than later.

Discussions from v3/v4:
- Rick asked whether the assumption that the reserved bits in
  CPUID.0x1.EAX, CPUID.{0x4,0x18,0x1F} and CPUID.0x80000008.EAX won't be
  used to enumerate features can be confirmed by the x86 architects [3].
  Confirmation is still pending.  Per the SDM/APM, these leaves/registers
  are defined for specific information (version, cache/TLB parameters,
  topology, and address sizes), so the reserved bits are expected to be
  used to extend the existing information rather than to enumerate
  features.  Allowing these registers in full is a best guess, but it's
  still far better than the existing denylist-based check.

- Whether to restrict the TDX feature bits to kvm_cpu_caps[].
  The conclusion from the discussions is to construct the allowlist based
  on kvm_cpu_caps[], plus a few bits that KVM can support for TDs
  independently of kvm_cpu_caps[].  If TDX feature enabling turns out to
  be consistently blocked by non-TDX VM enabling, a solution can be worked
  out then.

- New opt-in interface vs. backporting.
  There are two options for old KVM versions that don't do the filtering
  and validation:
  1) Add a new opt-in interface to expose features newly introduced by the
     TDX module.
  2) Backport this series to LTS/stable branches.

  The opt-in design vs. backport decision is deferred, since this series
  is correct and an improvement either way.

- Potential backward compatibility issue when an effective fixed-1 bit
  becomes directly configurable due to x86 feature deprecation.
  This is left for the future, i.e. it can be addressed if and when such a
  deprecation actually happens, e.g. by adding an opt-in interface to let
  users/admins choose between migration flexibility and backwards
  compatibility on old platforms.

Changes since v4 [1]:
- Split the CPUID entry index check out into a standalone fix, which
  allows it to be backported to stable independently of the rest of the
  series.
- Exclude XTPR from the allowlist, as neither TDX nor KVM actually
  virtualizes the feature and guests don't need it. (Xiaoyao, Rick)
- Rename TDX_CFG_EXTRA_F() to TDX_CFG_INDEPENDENT_F(). (Xiaoyao)
- Fix AMX_COMPLEX to be added for CPUID_7_1_EDX instead of CPUID_1E_1_EAX.
- Drop the descriptions in the TDX documentation and the uapi header, as
  the ioctl interfaces for KVM_TDX_CAPABILITIES and KVM_TDX_INIT_VM are
  unchanged by this patch series.
- Improve changelogs and comments. (Xiaoyao, Rick)

The series follows the CSV version of the CPUID virtualization document
from "Intel TDX Module ABI Definitions" [4], updated in June 2026.

AI tools were used to:
- Polish the cover letter and commit messages.
- Do code review.

[1] v4: https://lore.kernel.org/all/20260917072548.2314491-1-binbin.wu@linux.intel.com
    v3: https://lore.kernel.org/all/20260827031837.2863609-1-binbin.wu@linux.intel.com
    v2: https://lore.kernel.org/all/20260604023314.3907511-1-binbin.wu@linux.intel.com
    v1: https://lore.kernel.org/all/20260417073610.3246316-1-binbin.wu@linux.intel.com
[2] https://lore.kernel.org/all/20260911213659.2025974-1-sohil.mehta@intel.com
[3] https://lore.kernel.org/all/e7182b3c03a0e39cb60392b4d75111255418d6cf.camel@intel.com
[4] https://cdrdv2.intel.com/v1/dl/getContent/795381

Binbin Wu (5):
  KVM: TDX: Check unsupported CPUID bits against the TDX module's
    subleaf
  KVM: TDX: Track configurable CPUID bits allowed by KVM
  KVM: TDX: Add CORE_CAPABILITIES to the allowlist
  KVM: TDX: Report only KVM-allowed CPUIDs in KVM_TDX_CAPABILITIES
  KVM: TDX: Validate userspace CPUID input for KVM_TDX_INIT_VM

 arch/x86/kvm/vmx/tdx.c | 258 ++++++++++++++++++++++++++++++++++++-----
 1 file changed, 231 insertions(+), 27 deletions(-)


base-commit: dea4f6380f4ec96e8f3b0aaf2343764bd0d25ef4
-- 
2.46.0