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

[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@linux.intel.com
    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/b196cf9f65fe1e52aba7b867b7c2687c40caa337.camel@intel.com
[3] https://lore.kernel.org/all/20261022210134.612848-1-seanjc@google.com
[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@google.com>
-- 
2.46.0

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

[Binbin Wu]

Add tdx_cpu_cfg_caps[] to track the subset of TDX directly configurable
CPUID feature bits that KVM supports, and initialize it during TDX
hardware setup.

The TDX module reports the CPUID bits that the VMM can directly configure
for a TD, but KVM can't blindly expose every reported bit to userspace.
Some features imply additional state, e.g. MSRs, that KVM must context
switch across host/guest transitions to avoid corrupting host state.  The
existing hardcoded denylist can't account for such features introduced by
future TDX modules.

Aside from a few fixed-1 bits required for basic TDX support, features
that can clobber host state are either directly configurable or controlled
by TD ATTRIBUTES/XFAM, which KVM already validates.  Thus, an allowlist
covering only the directly configurable bits is sufficient.

Organize tdx_cpu_cfg_caps[] like kvm_cpu_caps[] so that the allowlist can
be built with feature-name based initializers.  Directly configurable bits
that aren't feature flags will be handled when building the per-register
masks for KVM_TDX_CAPABILITIES.

Sort the directly configurable CPUID feature bits into three categories:

 1) Features that KVM supports and tracks in kvm_cpu_caps[].  Use
    TDX_CFG_F() so that they are also capped by kvm_cpu_caps[].

 2) Features that KVM supports, or can safely allow, but doesn't track in
    kvm_cpu_caps[], i.e. MWAIT and HT.  Use TDX_CFG_INDEPENDENT_F().

 3) Features that are obsolete or unsupported by KVM, and thus excluded,
    i.e. EST, TM2, CID, SDBG, XTPR, DCA, PN (PSN), ACPI, ACC (TM), PBE,
    HLE, RTM, CQM (RDT_M), RDT_A, PREFETCHWT1, WAITPKG, TME, PCONFIG,
    CORE_CAPABILITIES, RAO_INT, FRED, and AMX-TRANSPOSE.

Excluding the features in category 3 shouldn't break userspace, as
userspace is expected to consult KVM_TDX_CAPABILITIES for the configurable
bits before invoking KVM_TDX_INIT_VM.  Nor should it break guests, as the
features are either obsolete or unsupported by KVM, and in the latter case,
a guest relying on them would already have run into problems.
CORE_CAPABILITIES is a special case; it will be allowed separately to
accommodate its legacy fixed-1 definition.

Future changes will use tdx_cpu_cfg_caps[] to filter KVM_TDX_CAPABILITIES
and to reject unsupported CPUID input to KVM_TDX_INIT_VM, so that directly
configurable bits introduced by future TDX modules are neither advertised
to nor configurable by userspace until KVM explicitly opts in.

Signed-off-by: Binbin Wu <binbin.wu@linux.intel.com>
Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Reviewed-by: Chao Gao <chao.gao@intel.com>
Reviewed-by: Nikolay Borisov <nik.borisov@suse.com>
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
---
v6:
- Rebased on patch series "x86/cpuid: KVM: TDX CPUID fixes"
  https://lore.kernel.org/all/20261022210134.612848-1-seanjc@google.com
- Collected RBs. (Rick, Chao, Nikolay, Xiaoyao)

v5:
- Simplify the commit message for excluded bits. (Xiaoyao)
- Use TDX_CFG_INDEPENDENT_F() instead of TDX_CFG_EXTRA_F(). (Xiaoyao)
- Avoid using "patch" in the commit message. (Rick)
- Remove comments for host clobbering features KVM doesn't support yet.
  (Xiaoyao)
- AMX_COMPLEX should be added for CPUID_7_1_EDX instead of CPUID_1E_1_EAX,
  it was a wrong fix in v4 to add it for CPUID_1E_1_EAX.
- Exclude XTPR since TDX/KVM doesn't actually virtualize the feature and
  guests don't need it.
- Move the TDX CPUID allowlist code next to the other CPUID helpers.

v4:
- Add XTPR and HT to the allowlist.
- Explain in the changelog why some directly configurable bits are not
  added to the allowlist.
- Improve comments/changelog. (Xiaoyao)
- Fix the bug that AMX_COMPLEX should be added for CPUID_1E_1_EAX instead
  of CPUID_7_1_EDX.

v3:
- Drop the new data structure in v2 and only track feature bits by
  following the organization of kvm_cpu_caps[], handle non-feature
  bits separately. (Sean)
- Use two versions of macros (TDX_CFG_F() vs. TDX_CFG_EXTRA_F()) to
  distinguish whether a supported TDX configurable CPUID bit should be
  checked against KVM's common cpu capabilities.
- Add AMX_COMPLEX since it has been defined in the CPUID virtualization doc.
---
 arch/x86/kvm/vmx/tdx.c | 153 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 153 insertions(+)

diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
index 3fc68b00ccd02..b71460805c573 100644
--- a/arch/x86/kvm/vmx/tdx.c
+++ b/arch/x86/kvm/vmx/tdx.c
@@ -58,6 +58,8 @@ bool enable_tdx __ro_after_init;
 module_param_named(tdx, enable_tdx, bool, 0444);
 
 static const struct tdx_sys_info *tdx_sysinfo;
+static u32 tdx_cpu_cfg_caps[NR_KVM_CPU_CAPS] __ro_after_init;
+static_assert(ARRAY_SIZE(tdx_cpu_cfg_caps) == ARRAY_SIZE(kvm_cpu_caps));
 
 void tdh_vp_rd_failed(struct vcpu_tdx *tdx, char *uclass, u32 field, u64 err)
 {
@@ -118,6 +120,155 @@ static u32 tdx_set_guest_phys_addr_bits(const u32 eax, int addr_bits)
 	return (eax & ~GENMASK(23, 16)) | (addr_bits & 0xff) << 16;
 }
 
+#define TDX_VALIDATE_CPU_CAP_USAGE(name)			\
+	BUILD_BUG_ON(__feature_leaf(X86_FEATURE_##name) !=	\
+		     tdx_cpu_cap_init_in_progress)
+
+/* For features that are dependent on kvm_cpu_caps[]. */
+#define TDX_CFG_F(name)					\
+({							\
+	TDX_VALIDATE_CPU_CAP_USAGE(name);		\
+	tdx_cfg_caps |= feature_bit(name);		\
+})
+
+/*
+ * For features that are not dependent on kvm_cpu_caps[], e.g. MWAIT.
+ * Use this version only when there is a justification.
+ */
+#define TDX_CFG_INDEPENDENT_F(name)			\
+({							\
+	TDX_VALIDATE_CPU_CAP_USAGE(name);		\
+	tdx_cfg_caps_independent |= feature_bit(name);	\
+})
+
+#define tdx_cpu_cfg_cap_init(leaf, feature_initializers...)		\
+do {									\
+	const u32 __maybe_unused tdx_cpu_cap_init_in_progress = leaf;	\
+	u32 tdx_cfg_caps_independent = 0;				\
+	u32 tdx_cfg_caps = 0;						\
+									\
+	feature_initializers						\
+	tdx_cpu_cfg_caps[leaf] = (tdx_cfg_caps & kvm_cpu_caps[leaf]) |	\
+				 tdx_cfg_caps_independent;		\
+} while (0)
+
+/*
+ * Initialize tdx_cpu_cfg_caps[], the list of CPUID features that KVM
+ * supports for TDX guests.  It covers only the directly configurable CPUID
+ * bits reported by the TDX module; features controlled by XFAM and
+ * ATTRIBUTES are handled separately.
+ */
+static void __init tdx_initialize_cpu_cfg_caps(void)
+{
+	tdx_cpu_cfg_cap_init(CPUID_1_ECX,
+		/*
+		 * KVM allows userspace to enumerate MONITOR+MWAIT support to
+		 * the guest, but the MWAIT feature flag is never advertised
+		 * to userspace for non-TDX VMs.
+		 */
+		TDX_CFG_INDEPENDENT_F(MWAIT),
+		TDX_CFG_F(TSC_DEADLINE_TIMER),
+		TDX_CFG_F(AVX),
+		TDX_CFG_F(F16C),
+	);
+
+	tdx_cpu_cfg_cap_init(CPUID_1_EDX,
+		TDX_CFG_F(MCE),
+		TDX_CFG_F(MTRR),
+		TDX_CFG_F(MCA),
+		TDX_CFG_F(SELFSNOOP),
+		/*
+		 * HT is a topology enumeration bit that KVM doesn't care
+		 * about, but userspace may want to expose it to the guests.
+		 */
+		TDX_CFG_INDEPENDENT_F(HT),
+	);
+
+	tdx_cpu_cfg_cap_init(CPUID_7_0_EBX,
+		TDX_CFG_F(BMI1),
+		TDX_CFG_F(BMI2),
+		TDX_CFG_F(ERMS),
+		TDX_CFG_F(AVX512F),
+		TDX_CFG_F(AVX512DQ),
+		TDX_CFG_F(ADX),
+		TDX_CFG_F(AVX512IFMA),
+		TDX_CFG_F(AVX512PF),
+		TDX_CFG_F(AVX512ER),
+		TDX_CFG_F(AVX512CD),
+		TDX_CFG_F(AVX512BW),
+		TDX_CFG_F(AVX512VL),
+	);
+
+	tdx_cpu_cfg_cap_init(CPUID_7_ECX,
+		TDX_CFG_F(UMIP),
+		TDX_CFG_F(AVX512_VBMI2),
+		TDX_CFG_F(GFNI),
+		TDX_CFG_F(VAES),
+		TDX_CFG_F(VPCLMULQDQ),
+		TDX_CFG_F(AVX512_VNNI),
+		TDX_CFG_F(AVX512_BITALG),
+		TDX_CFG_F(AVX512_VPOPCNTDQ),
+		TDX_CFG_F(LA57),
+		TDX_CFG_F(RDPID),
+		TDX_CFG_F(CLDEMOTE),
+	);
+
+	tdx_cpu_cfg_cap_init(CPUID_7_EDX,
+		TDX_CFG_F(AVX512_4VNNIW),
+		TDX_CFG_F(AVX512_4FMAPS),
+		TDX_CFG_F(FSRM),
+		TDX_CFG_F(AVX512_VP2INTERSECT),
+		TDX_CFG_F(SERIALIZE),
+		TDX_CFG_F(TSXLDTRK),
+	);
+
+	tdx_cpu_cfg_cap_init(CPUID_7_1_EAX,
+		TDX_CFG_F(SHA512),
+		TDX_CFG_F(SM3),
+		TDX_CFG_F(SM4),
+		TDX_CFG_F(AVX_VNNI),
+		TDX_CFG_F(AVX512_BF16),
+		TDX_CFG_F(CMPCCXADD),
+		TDX_CFG_F(FZRM),
+		TDX_CFG_F(FSRS),
+		TDX_CFG_F(FSRC),
+		TDX_CFG_F(LKGS),
+		TDX_CFG_F(WRMSRNS),
+		TDX_CFG_F(AMX_FP16),
+		TDX_CFG_F(AVX_IFMA),
+		TDX_CFG_F(LAM),
+		TDX_CFG_F(MOVRS),
+	);
+
+	tdx_cpu_cfg_cap_init(CPUID_7_1_EDX,
+		TDX_CFG_F(AVX_VNNI_INT8),
+		TDX_CFG_F(AVX_NE_CONVERT),
+		TDX_CFG_F(AMX_COMPLEX),
+		TDX_CFG_F(AVX_VNNI_INT16),
+		TDX_CFG_F(PREFETCHITI),
+		TDX_CFG_F(AVX10),
+	);
+
+	tdx_cpu_cfg_cap_init(CPUID_7_2_EDX,
+		TDX_CFG_F(DDPD_U),
+		TDX_CFG_F(MCDT_NO),
+	);
+
+	tdx_cpu_cfg_cap_init(CPUID_1E_1_EAX,
+		TDX_CFG_F(AMX_FP8),
+		TDX_CFG_F(AMX_TF32),
+		TDX_CFG_F(AMX_AVX512),
+		TDX_CFG_F(AMX_MOVRS),
+	);
+
+	tdx_cpu_cfg_cap_init(CPUID_8000_0008_EBX,
+		TDX_CFG_F(WBNOINVD),
+	);
+}
+
+#undef TDX_CFG_F
+#undef TDX_CFG_INDEPENDENT_F
+
 #define TDX_FEATURE_TSX (__feature_bit(X86_FEATURE_HLE) | __feature_bit(X86_FEATURE_RTM))
 
 static bool has_tsx(const struct kvm_cpuid_entry2 *entry)
@@ -3539,6 +3690,8 @@ int __init tdx_hardware_setup(void)
 		return r;
 	}
 
+	tdx_initialize_cpu_cfg_caps();
+
 	KVM_SANITY_CHECK_VM_STRUCT_SIZE(kvm_tdx);
 
 	vt_x86_ops.vm_size = max_t(unsigned int, vt_x86_ops.vm_size, sizeof(struct kvm_tdx));
-- 
2.46.0

[PATCH v6 2/4] KVM: TDX: Add CORE_CAPABILITIES to the allowlist

[Binbin Wu]

Add CORE_CAPABILITIES (CPUID.0x7.0.EDX[30]) to KVM's allowlist of TDX
directly configurable CPUID feature bits to accommodate the legacy TDX
module definition of the bit, even though KVM doesn't support
MSR_IA32_CORE_CAPS for TDs.

Older TDX module specs define CORE_CAPABILITIES as fixed-1, so userspace
may expect the bit to be set for TDs.  The bit is redefined as directly
configurable due to #VE reduction.  Leaving it out of the allowlist would
prevent userspace from setting it once KVM starts validating the CPUID
input to KVM_TDX_INIT_VM, which would be an unexpected behavior change for
such userspace.

Reporting CORE_CAPABILITIES as directly configurable also lets userspace
detect that the bit is no longer fixed-1, and thus update its stale
knowledge.

Keep MSR_IA32_CORE_CAPS unsupported for TDs, as no existing TDX user needs
guest access to the MSR.

Note, CORE_CAPABILITIES is the only bit that is both unsupported by KVM
*and* redefined from fixed-1 to directly configurable due to #VE
reduction, and no further #VE reductions are expected.

Signed-off-by: Binbin Wu <binbin.wu@linux.intel.com>
Reviewed-by: Tony Lindgren <tony.lindgren@linux.intel.com>
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Reviewed-by: Chao Gao <chao.gao@intel.com>
Reviewed-by: Nikolay Borisov <nik.borisov@suse.com>
---
v6:
- Rebased on patch series "x86/cpuid: KVM: TDX CPUID fixes"
  https://lore.kernel.org/all/20261022210134.612848-1-seanjc@google.com
- Collected RBs. (Rick, Chao, Nikolay)

v5:
- Clarify in the changelog that #VE reduction redefines the bit from
  fixed-1 to directly configurable.
- Change the shortlog from "KVM: TDX: Report CORE_CAPABILITIES as
  configurable" to "KVM: TDX: Add CORE_CAPABILITIES to the allowlist"
  since the patch doesn't change the CPUID reporting behavior yet.
- Add RB from Xiaoyao.

v4:
- Add #VE reduction related background to the changelog. (Kishen)
- Add RB from Tony.

v3:
- Drop the code for MSR_IA32_CORE_CAPS access.
---
 arch/x86/kvm/vmx/tdx.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
index b71460805c573..becdd5aa9e682 100644
--- a/arch/x86/kvm/vmx/tdx.c
+++ b/arch/x86/kvm/vmx/tdx.c
@@ -220,6 +220,13 @@ static void __init tdx_initialize_cpu_cfg_caps(void)
 		TDX_CFG_F(AVX512_VP2INTERSECT),
 		TDX_CFG_F(SERIALIZE),
 		TDX_CFG_F(TSXLDTRK),
+		/*
+		 * KVM doesn't support MSR_IA32_CORE_CAPS, but older TDX module
+		 * specs define this bit as fixed-1.  Report it as configurable
+		 * to accommodate the legacy TDX module definition, and to let
+		 * userspace detect that the bit is no longer fixed-1.
+		 */
+		TDX_CFG_INDEPENDENT_F(CORE_CAPABILITIES),
 	);
 
 	tdx_cpu_cfg_cap_init(CPUID_7_1_EAX,
-- 
2.46.0

[PATCH v6 3/4] KVM: TDX: Report only KVM-allowed CPUID bits in KVM_TDX_CAPABILITIES

[Binbin Wu]

Filter the directly configurable CPUID bits reported through
KVM_TDX_CAPABILITIES against KVM's TDX allowlist, and drop the hardcoded
denylist-based filtering.

The TDX module reports the CPUID bits that the VMM can directly configure
for a TD, but KVM must not advertise bits that it doesn't support, as
blindly exposing a feature that clobbers host state can corrupt the host.
The existing denylist, which clears only TSX and WAITPKG, can't account
for such features introduced by future TDX modules.

Add tdx_get_cpuid_cfg_mask() to compute the mask of directly configurable
bits that KVM allows for a given CPUID register, and apply it to every
CPUID entry reported through KVM_TDX_CAPABILITIES.  The mask combines
feature bits, taken from tdx_cpu_cfg_caps[], with non-feature bits, which
are identified by function, index, and register.

Treat CPUID.0x1.{EAX,EBX}, CPUID.{0x4,0x18,0x1F}, and CPUID.0x80000008.EAX
as fully allowed, as these registers enumerate non-feature information,
e.g. family/model/stepping, brand index, CLFLUSH line size, APIC ID,
cache/TLB/topology properties, and address sizes.  Allow the reserved bits
in them as well.  Though there's no architectural guarantee, given what
these registers enumerate, the reserved bits are expected to be used to
extend the existing information rather than to enumerate new features.

Also allow CPUID.0x24.0.EBX[7:0] (AVX10 version), which the TDX module
reports as directly configurable when AVX10 is supported, even though the
CPUID virtualization table in the "Intel TDX Module ABI Definitions"
currently lists it as not configurable.  The table is expected to be
corrected.

As a result, directly configurable bits that aren't in the allowlist,
including bits introduced by future TDX modules, aren't advertised to
userspace until KVM explicitly opts in.

Note, this is an ABI change, as some bits that were previously reported as
configurable no longer are.  However, the semantics of
KVM_TDX_CAPABILITIES are unchanged: KVM already filtered unsupported bits
out of KVM_TDX_CAPABILITIES, albeit via a denylist, and the set of
reported bits already varies with the TDX module and KVM versions, i.e.
userspace can't assume a fixed set.

The change isn't expected to break userspace or guests:
 - Userspace that honors KVM_TDX_CAPABILITIES simply stops setting the
   dropped bits, and KVM_TDX_INIT_VM still succeeds.
 - CORE_CAPABILITIES, which older TDX module specs defined as fixed-1, is
   still allowed.
 - The dropped features are either obsolete or unsupported by KVM, and in
   the latter case, a guest relying on them would already have run into
   problems.

Signed-off-by: Binbin Wu <binbin.wu@linux.intel.com>
Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Reviewed-by: Chao Gao <chao.gao@intel.com>
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
---
v6:
- Rebased on patch series "x86/cpuid: KVM: TDX CPUID fixes"
  https://lore.kernel.org/all/20261022210134.612848-1-seanjc@google.com
- Fix the changelog on ABI change. (Rick)
- Collected RBs. (Rick, Chao, Xiaoyao)

v5:
- Change the shortlog to make the change more clear.
- Update the changelog to call out the user-visible change more loudly.
  (Rick)
- Describe CPUID.0x24.0.EBX[7:0] in the changelog rather than in a code
  comment, since the comment would become stale once the spec is updated.
- Update the changelog/comments for the CPUIDs that are expected not to be
  repurposed to hold feature bits according to their definitions.
- Drop the note in the TDX document as the semantic of KVM_TDX_CAPABILITIES
  is unchanged.

v4:
- Rename functions. (Tony)
  tdx_cfg_non_feature_mask()       -> tdx_get_cpuid_cfg_non_feature_mask()
  tdx_cfg_feature_mask()           -> tdx_get_cpuid_cfg_feature_mask()
  tdx_get_allowed_cfg_cpuid_mask() -> tdx_get_cpuid_cfg_mask()
- Update documentation. (Xiaoyao, Rick)

v3:
- Handle non-feature leafs at runtime. (Sean)
- Add CPUID.0x24.0.EBX[7:0] into allowlist. There is a mismatch of the
  description about CPUID.0x24.0.EBX[7:0], which is listed as
  "XFAM & CPUID_Enabled & Native" but should be "XFAM & CPUID_Enabled &
  Configured & Native".
---
 arch/x86/kvm/vmx/tdx.c | 97 ++++++++++++++++++++++++++++++++----------
 1 file changed, 74 insertions(+), 23 deletions(-)

diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
index becdd5aa9e682..0741c3ef4745e 100644
--- a/arch/x86/kvm/vmx/tdx.c
+++ b/arch/x86/kvm/vmx/tdx.c
@@ -284,31 +284,12 @@ static bool has_tsx(const struct kvm_cpuid_entry2 *entry)
 	       (entry->ebx & TDX_FEATURE_TSX);
 }
 
-static void clear_tsx(struct kvm_cpuid_entry2 *entry)
-{
-	entry->ebx &= ~TDX_FEATURE_TSX;
-}
-
 static bool has_waitpkg(const struct kvm_cpuid_entry2 *entry)
 {
 	return entry->function == 7 && entry->index == 0 &&
 	       (entry->ecx & __feature_bit(X86_FEATURE_WAITPKG));
 }
 
-static void clear_waitpkg(struct kvm_cpuid_entry2 *entry)
-{
-	entry->ecx &= ~__feature_bit(X86_FEATURE_WAITPKG);
-}
-
-static void tdx_clear_unsupported_cpuid(struct kvm_cpuid_entry2 *entry)
-{
-	if (has_tsx(entry))
-		clear_tsx(entry);
-
-	if (has_waitpkg(entry))
-		clear_waitpkg(entry);
-}
-
 static bool tdx_is_unsupported_cpuid_entry(const struct kvm_cpuid_entry2 *entry)
 {
 	if (cpuid_function_is_indexed(entry->function) !=
@@ -318,6 +299,70 @@ static bool tdx_is_unsupported_cpuid_entry(const struct kvm_cpuid_entry2 *entry)
 	return has_tsx(entry) || has_waitpkg(entry);
 }
 
+#define TDX_CPUID_ALL_ALLOWED_MASK	GENMASK_U32(31, 0)
+
+static u32 tdx_get_cpuid_cfg_non_feature_mask(u32 function, u32 index, int reg)
+{
+	/*
+	 * Allow all bits in registers that enumerate non-feature information.
+	 * Note, CPUID.0x1.EAX, CPUID.{0x4, 0x18, 0x1f} and CPUID.0x80000008.EAX
+	 * contain reserved bits.  Though not architecturally guaranteed, the
+	 * reserved bits are expected to be used to extend the existing
+	 * information rather than to enumerate features, so allow them too.
+	 */
+	switch (function) {
+	case 0x1:
+		if (reg == CPUID_EAX || reg == CPUID_EBX)
+			return TDX_CPUID_ALL_ALLOWED_MASK;
+		return 0;
+	case 0x4:
+	case 0x18:
+	case 0x1f:
+		return TDX_CPUID_ALL_ALLOWED_MASK;
+	case 0x24:
+		if (index == 0 && reg == CPUID_EBX)
+			return GENMASK_U32(7, 0);
+		return 0;
+	case 0x80000008:
+		if (reg == CPUID_EAX)
+			return TDX_CPUID_ALL_ALLOWED_MASK;
+		return 0;
+	default:
+		return 0;
+	}
+}
+
+static u32 tdx_get_cpuid_cfg_feature_mask(u32 function, u32 index, int reg)
+{
+	for (int i = 0; i < NR_KVM_CPU_CAPS; i++) {
+		const struct cpuid_reg *cpuid = &reverse_cpuid[i];
+
+		if (!cpuid->function)
+			continue;
+
+		if (cpuid->function == function && cpuid->index == index &&
+		    cpuid->reg == reg)
+			return tdx_cpu_cfg_caps[i];
+	}
+
+	return 0;
+}
+
+static u32 tdx_get_cpuid_cfg_mask(u32 function, u32 index, int reg)
+{
+	u32 non_feature_mask = tdx_get_cpuid_cfg_non_feature_mask(function, index, reg);
+
+	/* Skip reverse_cpuid[] walk if it's already all allowed. */
+	if (non_feature_mask == TDX_CPUID_ALL_ALLOWED_MASK)
+		return TDX_CPUID_ALL_ALLOWED_MASK;
+
+	/*
+	 * It's possible that a CPUID register contains both feature and
+	 * non-feature bits.
+	 */
+	return non_feature_mask | tdx_get_cpuid_cfg_feature_mask(function, index, reg);
+}
+
 #define KVM_TDX_CPUID_NO_SUBLEAF	((__u32)-1)
 
 static void td_init_cpuid_entry2(struct kvm_cpuid_entry2 *entry, unsigned char idx)
@@ -352,8 +397,6 @@ static void td_init_cpuid_entry2(struct kvm_cpuid_entry2 *entry, unsigned char i
 	 */
 	if (entry->function == 0x80000008)
 		entry->eax = tdx_set_guest_phys_addr_bits(entry->eax, 0xff);
-
-	tdx_clear_unsupported_cpuid(entry);
 }
 
 #define TDVMCALLINFO_SETUP_EVENT_NOTIFY_INTERRUPT	BIT(1)
@@ -376,8 +419,16 @@ static int init_kvm_tdx_caps(const struct tdx_sys_info_td_conf *td_conf,
 	caps->user_tdvmcallinfo_1_r11 =
 		TDVMCALLINFO_SETUP_EVENT_NOTIFY_INTERRUPT;
 
-	for (i = 0; i < td_conf->num_cpuid_config; i++)
-		td_init_cpuid_entry2(&caps->cpuid.entries[i], i);
+	for (i = 0; i < td_conf->num_cpuid_config; i++) {
+		struct kvm_cpuid_entry2 *e = &caps->cpuid.entries[i];
+
+		td_init_cpuid_entry2(e, i);
+		/* Only report the configurable bits allowed by KVM. */
+		e->eax &= tdx_get_cpuid_cfg_mask(e->function, e->index, CPUID_EAX);
+		e->ebx &= tdx_get_cpuid_cfg_mask(e->function, e->index, CPUID_EBX);
+		e->ecx &= tdx_get_cpuid_cfg_mask(e->function, e->index, CPUID_ECX);
+		e->edx &= tdx_get_cpuid_cfg_mask(e->function, e->index, CPUID_EDX);
+	}
 
 	return 0;
 }
-- 
2.46.0

[PATCH v6 4/4] KVM: TDX: Validate userspace CPUID input for KVM_TDX_INIT_VM

[Binbin Wu]

Validate the CPUID configuration provided by userspace through
KVM_TDX_INIT_VM against KVM's TDX allowlist, and drop the hardcoded
denylist-based check.

The TDX module lets the VMM directly configure certain CPUID bits for a TD
at initialization time, but KVM must strictly govern which of those bits
userspace can set, otherwise a feature that clobbers host state could be
enabled behind KVM's back.  The existing denylist rejects only TSX and
WAITPKG, and thus would accept any bit that a future TDX module makes
configurable, even if KVM knows nothing about the associated feature.

Rewrite tdx_is_unsupported_cpuid_entry() to reject KVM_TDX_INIT_VM if
userspace sets any bit outside of the mask returned by
tdx_get_cpuid_cfg_mask(), i.e. the same mask used to filter
KVM_TDX_CAPABILITIES.  Don't bother intersecting the userspace input with
the bits that the TDX module reports as directly configurable, as the TDX
module itself rejects any bit outside that set.

Ignore the index for non-indexed functions when walking reverse_cpuid[],
as userspace isn't required to zero it.

Note, this is an ABI change, as KVM_TDX_INIT_VM now rejects some input
that was previously accepted.  However, the semantics of KVM_TDX_INIT_VM
are unchanged: KVM already rejected unsupported CPUID bits, albeit via a
denylist, and userspace has always been required to consult
KVM_TDX_CAPABILITIES and set only the bits reported as configurable.

The change isn't expected to break userspace or guests:
 - The newly rejected bits are no longer reported as configurable by
   KVM_TDX_CAPABILITIES, so userspace that honors KVM_TDX_CAPABILITIES
   won't set them.
 - CORE_CAPABILITIES, which older TDX module specs defined as fixed-1, is
   still allowed.
 - The newly rejected features are either obsolete or unsupported by KVM,
   and in the latter case, a guest relying on them would already have run
   into problems.

Signed-off-by: Binbin Wu <binbin.wu@linux.intel.com>
Reviewed-by: Tony Lindgren <tony.lindgren@linux.intel.com>
Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Reviewed-by: Chao Gao <chao.gao@intel.com>
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
---
v6:
- Rebased on patch series "x86/cpuid: KVM: TDX CPUID fixes"
  https://lore.kernel.org/all/20261022210134.612848-1-seanjc@google.com
- Ignore the index for non-indexed functions when walking reverse_cpuid[].
- Fix the changelog on ABI change. (Rick)
- Collected RBs. (Rick, Chao, Xiaoyao)

v5:
- Update the changelog and call out the user-visible change more loudly.
  (Rick)
- Drop the description in TDX document and the uapi header, as the ABI
  itself is unchanged.
- Split the CPUID entry index check out to a separate fix patch.

v4:
- Update the comments/documentation.
- Collect RB tag from Tony.

v3:
- Check CPUID entry index mismatch b/t userspace input and TDX sysinfo
  configuration. (Sashiko)
- No need to mask the userspace input with TDX module reported directly
  configurable bits first, since the userspace input should be subset of
  directly configurable bits. Otherwise, the input will be rejected by
  the TDX module.
---
 arch/x86/kvm/vmx/tdx.c | 41 ++++++++++++++++-------------------------
 1 file changed, 16 insertions(+), 25 deletions(-)

diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
index 0741c3ef4745e..9b4e7db555347 100644
--- a/arch/x86/kvm/vmx/tdx.c
+++ b/arch/x86/kvm/vmx/tdx.c
@@ -276,29 +276,6 @@ static void __init tdx_initialize_cpu_cfg_caps(void)
 #undef TDX_CFG_F
 #undef TDX_CFG_INDEPENDENT_F
 
-#define TDX_FEATURE_TSX (__feature_bit(X86_FEATURE_HLE) | __feature_bit(X86_FEATURE_RTM))
-
-static bool has_tsx(const struct kvm_cpuid_entry2 *entry)
-{
-	return entry->function == 7 && entry->index == 0 &&
-	       (entry->ebx & TDX_FEATURE_TSX);
-}
-
-static bool has_waitpkg(const struct kvm_cpuid_entry2 *entry)
-{
-	return entry->function == 7 && entry->index == 0 &&
-	       (entry->ecx & __feature_bit(X86_FEATURE_WAITPKG));
-}
-
-static bool tdx_is_unsupported_cpuid_entry(const struct kvm_cpuid_entry2 *entry)
-{
-	if (cpuid_function_is_indexed(entry->function) !=
-	    !!(entry->flags & KVM_CPUID_FLAG_SIGNIFCANT_INDEX))
-		return true;
-
-	return has_tsx(entry) || has_waitpkg(entry);
-}
-
 #define TDX_CPUID_ALL_ALLOWED_MASK	GENMASK_U32(31, 0)
 
 static u32 tdx_get_cpuid_cfg_non_feature_mask(u32 function, u32 index, int reg)
@@ -334,14 +311,16 @@ static u32 tdx_get_cpuid_cfg_non_feature_mask(u32 function, u32 index, int reg)
 
 static u32 tdx_get_cpuid_cfg_feature_mask(u32 function, u32 index, int reg)
 {
+	bool is_indexed = cpuid_function_is_indexed(function);
+
 	for (int i = 0; i < NR_KVM_CPU_CAPS; i++) {
 		const struct cpuid_reg *cpuid = &reverse_cpuid[i];
 
 		if (!cpuid->function)
 			continue;
 
-		if (cpuid->function == function && cpuid->index == index &&
-		    cpuid->reg == reg)
+		if (cpuid->function == function &&
+		    (!is_indexed || cpuid->index == index) && cpuid->reg == reg)
 			return tdx_cpu_cfg_caps[i];
 	}
 
@@ -433,6 +412,18 @@ static int init_kvm_tdx_caps(const struct tdx_sys_info_td_conf *td_conf,
 	return 0;
 }
 
+static bool tdx_is_unsupported_cpuid_entry(const struct kvm_cpuid_entry2 *entry)
+{
+	if (cpuid_function_is_indexed(entry->function) !=
+	    !!(entry->flags & KVM_CPUID_FLAG_SIGNIFCANT_INDEX))
+		return true;
+
+	return (entry->eax & ~tdx_get_cpuid_cfg_mask(entry->function, entry->index, CPUID_EAX)) ||
+	       (entry->ebx & ~tdx_get_cpuid_cfg_mask(entry->function, entry->index, CPUID_EBX)) ||
+	       (entry->ecx & ~tdx_get_cpuid_cfg_mask(entry->function, entry->index, CPUID_ECX)) ||
+	       (entry->edx & ~tdx_get_cpuid_cfg_mask(entry->function, entry->index, CPUID_EDX));
+}
+
 /*
  * Some SEAMCALLs acquire the TDX module globally, and can fail with
  * TDX_OPERAND_BUSY.  Use a global mutex to serialize these SEAMCALLs.
-- 
2.46.0

Re: [PATCH v6 3/4] KVM: TDX: Report only KVM-allowed CPUID bits in KVM_TDX_CAPABILITIES

[Nikolay Borisov]

On 28.10.26 г. 10:16 ч., Binbin Wu wrote:
> Filter the directly configurable CPUID bits reported through
> KVM_TDX_CAPABILITIES against KVM's TDX allowlist, and drop the hardcoded
> denylist-based filtering.
> 
> The TDX module reports the CPUID bits that the VMM can directly configure
> for a TD, but KVM must not advertise bits that it doesn't support, as
> blindly exposing a feature that clobbers host state can corrupt the host.
> The existing denylist, which clears only TSX and WAITPKG, can't account
> for such features introduced by future TDX modules.
> 
> Add tdx_get_cpuid_cfg_mask() to compute the mask of directly configurable
> bits that KVM allows for a given CPUID register, and apply it to every
> CPUID entry reported through KVM_TDX_CAPABILITIES.  The mask combines
> feature bits, taken from tdx_cpu_cfg_caps[], with non-feature bits, which
> are identified by function, index, and register.
> 
> Treat CPUID.0x1.{EAX,EBX}, CPUID.{0x4,0x18,0x1F}, and CPUID.0x80000008.EAX
> as fully allowed, as these registers enumerate non-feature information,
> e.g. family/model/stepping, brand index, CLFLUSH line size, APIC ID,
> cache/TLB/topology properties, and address sizes.  Allow the reserved bits
> in them as well.  Though there's no architectural guarantee, given what
> these registers enumerate, the reserved bits are expected to be used to
> extend the existing information rather than to enumerate new features.
> 
> Also allow CPUID.0x24.0.EBX[7:0] (AVX10 version), which the TDX module
> reports as directly configurable when AVX10 is supported, even though the
> CPUID virtualization table in the "Intel TDX Module ABI Definitions"
> currently lists it as not configurable.  The table is expected to be
> corrected.
> 
> As a result, directly configurable bits that aren't in the allowlist,
> including bits introduced by future TDX modules, aren't advertised to
> userspace until KVM explicitly opts in.
> 
> Note, this is an ABI change, as some bits that were previously reported as
> configurable no longer are.  However, the semantics of
> KVM_TDX_CAPABILITIES are unchanged: KVM already filtered unsupported bits
> out of KVM_TDX_CAPABILITIES, albeit via a denylist, and the set of
> reported bits already varies with the TDX module and KVM versions, i.e.
> userspace can't assume a fixed set.
> 
> The change isn't expected to break userspace or guests:
>   - Userspace that honors KVM_TDX_CAPABILITIES simply stops setting the
>     dropped bits, and KVM_TDX_INIT_VM still succeeds.
>   - CORE_CAPABILITIES, which older TDX module specs defined as fixed-1, is
>     still allowed.
>   - The dropped features are either obsolete or unsupported by KVM, and in
>     the latter case, a guest relying on them would already have run into
>     problems.
> 
> Signed-off-by: Binbin Wu <binbin.wu@linux.intel.com>
> Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Reviewed-by: Chao Gao <chao.gao@intel.com>
> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>

Reviewed-by: Nikolay Borisov <nik.borisov@suse.com>

Re: [PATCH v6 4/4] KVM: TDX: Validate userspace CPUID input for KVM_TDX_INIT_VM

[Nikolay Borisov]

On 28.10.26 г. 10:16 ч., Binbin Wu wrote:
> Validate the CPUID configuration provided by userspace through
> KVM_TDX_INIT_VM against KVM's TDX allowlist, and drop the hardcoded
> denylist-based check.
> 
> The TDX module lets the VMM directly configure certain CPUID bits for a TD
> at initialization time, but KVM must strictly govern which of those bits
> userspace can set, otherwise a feature that clobbers host state could be
> enabled behind KVM's back.  The existing denylist rejects only TSX and
> WAITPKG, and thus would accept any bit that a future TDX module makes
> configurable, even if KVM knows nothing about the associated feature.
> 
> Rewrite tdx_is_unsupported_cpuid_entry() to reject KVM_TDX_INIT_VM if
> userspace sets any bit outside of the mask returned by
> tdx_get_cpuid_cfg_mask(), i.e. the same mask used to filter
> KVM_TDX_CAPABILITIES.  Don't bother intersecting the userspace input with
> the bits that the TDX module reports as directly configurable, as the TDX
> module itself rejects any bit outside that set.
> 
> Ignore the index for non-indexed functions when walking reverse_cpuid[],
> as userspace isn't required to zero it.
> 
> Note, this is an ABI change, as KVM_TDX_INIT_VM now rejects some input
> that was previously accepted.  However, the semantics of KVM_TDX_INIT_VM
> are unchanged: KVM already rejected unsupported CPUID bits, albeit via a
> denylist, and userspace has always been required to consult
> KVM_TDX_CAPABILITIES and set only the bits reported as configurable.
> 
> The change isn't expected to break userspace or guests:
>   - The newly rejected bits are no longer reported as configurable by
>     KVM_TDX_CAPABILITIES, so userspace that honors KVM_TDX_CAPABILITIES
>     won't set them.
>   - CORE_CAPABILITIES, which older TDX module specs defined as fixed-1, is
>     still allowed.
>   - The newly rejected features are either obsolete or unsupported by KVM,
>     and in the latter case, a guest relying on them would already have run
>     into problems.
> 
> Signed-off-by: Binbin Wu <binbin.wu@linux.intel.com>
> Reviewed-by: Tony Lindgren <tony.lindgren@linux.intel.com>
> Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Reviewed-by: Chao Gao <chao.gao@intel.com>
> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>

Reviewed-by: Nikolay Borisov <nik.borisov@suse.com>