[PATCH v6 0/4] KVM: TDX: Validate directly configurable CPUID bits

[Binbin Wu]

Hi,

This is a quick respin of the TDX CPUID validation series (v5 [1]) to
address Rick's changelog comments [2] and to rebase on top of Sean's TDX
CPUID fixes series [3], which this series depends on.  Also, patch 4 now
ignores the index for non-indexed CPUID functions when looking up the
allowlist, as userspace isn't required to zero it.

I think this version is in good shape.  If there are no further concerns,
I'd appreciate it if this could be considered for queueing.

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.

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.
  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 v5 [1]:
- Dropped the bug fix patch in v5 and rebased on top of Sean's TDX CPUID
  fixes series [3].
- Changelog updates per Rick's comments [2].
- Collected RBs from Rick, Chao, Nikolay, Xiaoyao.
- Ignore the index for non-indexed functions when walking reverse_cpuid[].

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] v5: https://lore.kernel.org/all/20261016091422.3182216-1-binbin.wu@xxxxxxxxxxxxxxx
    v4: https://lore.kernel.org/all/20260917072548.2314491-1-binbin.wu@xxxxxxxxxxxxxxx
    v3: https://lore.kernel.org/all/20260827031837.2863609-1-binbin.wu@xxxxxxxxxxxxxxx
    v2: https://lore.kernel.org/all/20260604023314.3907511-1-binbin.wu@xxxxxxxxxxxxxxx
    v1: https://lore.kernel.org/all/20260417073610.3246316-1-binbin.wu@xxxxxxxxxxxxxxx
[2] https://lore.kernel.org/all/b196cf9f65fe1e52aba7b867b7c2687c40caa337.camel@xxxxxxxxx
[3] https://lore.kernel.org/all/20261022210134.612848-1-seanjc@xxxxxxxxxx
[4] https://cdrdv2.intel.com/v1/dl/getContent/795381

Binbin Wu (4):
  KVM: TDX: Track configurable CPUID bits allowed by KVM
  KVM: TDX: Add CORE_CAPABILITIES to the allowlist
  KVM: TDX: Report only KVM-allowed CPUID bits in KVM_TDX_CAPABILITIES
  KVM: TDX: Validate userspace CPUID input for KVM_TDX_INIT_VM

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


base-commit: dea4f6380f4ec96e8f3b0aaf2343764bd0d25ef4
prerequisite-message-id: <20261022210134.612848-1-seanjc@xxxxxxxxxx>
-- 
2.46.0