[PATCH v2 0/3] x86/cpuid: KVM: TDX CPUID fixes

[PATCH v2 0/3] x86/cpuid: KVM: TDX CPUID fixes

[Sean Christopherson]

Boris or Dave, can you grab patch 1 for 7.4, ideally sooner than later?  That
would avoid having to carry a stable topic branch for a trivial change.

Annotate CPUID entries that have a significant index when reporting TDX
capabilities to userspace, and enforce that userspace honors significant
indices to avoid creating a misconfiguring between KVM and the TDX Module,
which in the worst case scenario could lead to host state getting clobbered.

Patch 1 is a fix to mark function 0x23 as being indexed.  That change is
needed to avoid tripping a WARN sanity check that KVM and the TDX Module
agree on which functions are indexed.

I'd like to take this through the KVM tree as it seems extremely unlikely
the cpuid_function_is_indexed() will conflict or grow other dependencies,
i.e. creating a shared topic branch for this seems rather silly.  Actually,
a better alternative would be to rush patch 1 into 7.4 so that I can use
7.4-rc2 as a base (even rc3 or rc4 would be a-ok).  /me adds an intro

Note, SIGNIFCANT_INDEX isn't a typo, KVM's uAPI macro is misspelled...

v2:
 - Add CPUID.0x23 to the indexed set. [Rick, Binbin]
 - Document that zeroing the index when it's supposed to be ignored is KVM
   ABI that at least QEMU relies on. [Binbin]
 - Zero out all of flags to ensure garbage isn't reported to userspace.

v1: https://lore.kernel.org/all/20260223214336.722463-1-changyuanl@google.com

Changyuan Lyu (1):
  KVM: TDX: Set SIGNIFCANT_INDEX flag as appropriate when filling CPUID
    entries

Sean Christopherson (2):
  x86/cpuid: Mark CPUID function 0x23 as being indexed
  KVM: TDX: Reject KVM_TDX_INIT_VM if indexed CPUID functions don't
    match

 arch/x86/include/asm/cpuid/api.h |  1 +
 arch/x86/kvm/vmx/tdx.c           | 22 +++++++++++++++++++---
 2 files changed, 20 insertions(+), 3 deletions(-)


base-commit: 814607cd40df80d5727957adaa857e0feca43497
-- 
2.56.0.257.gf7497c7d27-goog

[PATCH v2 1/3] x86/cpuid: Mark CPUID function 0x23 as being indexed

[Sean Christopherson]

Add function 0x23 to the set of CPUID functions that are indexed, as per
the SDM and the many sub-leafs defined in leaf_types.h.

Reported-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Closes: https://lore.kernel.org/all/213d614fe73e183a230c8f4e0c8fa1cc3d45df39.camel@intel.com
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/include/asm/cpuid/api.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/include/asm/cpuid/api.h b/arch/x86/include/asm/cpuid/api.h
index 82eddfa2347b..25b22b173f2a 100644
--- a/arch/x86/include/asm/cpuid/api.h
+++ b/arch/x86/include/asm/cpuid/api.h
@@ -181,6 +181,7 @@ static __always_inline bool cpuid_function_is_indexed(u32 function)
 	case 0x1d:
 	case 0x1e:
 	case 0x1f:
+	case 0x23:
 	case 0x24:
 	case 0x8000001d:
 		return true;
-- 
2.56.0.257.gf7497c7d27-goog

[PATCH v2 2/3] KVM: TDX: Set SIGNIFCANT_INDEX flag as appropriate when filling CPUID entries

[Sean Christopherson]

From: Changyuan Lyu <changyuanl@google.com>

Set the KVM_CPUID_FLAG_SIGNIFCANT_INDEX flag in the kvm_cpuid_entry2
structures returned by KVM_TDX_CAPABILITIES if the CPUID is indexed,
otherwise KVM could confuse userspace and induce a configuration error.
This also ensures consistency with the CPUID entries returned by
KVM_GET_SUPPORTED_CPUID.

WARN if KVM and the TDX Module don't align on which functions have
significant indices, e.g. to help ensure the kernel is updated when the
TDX Module learns about new CPUID leaves, and vice versa.

Opportunistically add a comment to call out that zeroing the index when it
isn't significant is ABI that userspace relies on, e.g. QEMU looks for '0'
instead of checking KVM_CPUID_FLAG_SIGNIFCANT_INDEX.

Fixes: 61bb28279623 ("KVM: TDX: Get system-wide info about TDX module on initialization")
Cc: stable@vger.kernel.org
Cc: Binbin Wu <binbin.wu@linux.intel.com>
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Changyuan Lyu <changyuanl@google.com>
[sean: keep the WARN, don't key off KVM_TDX_CPUID_NO_SUBLEAF, add comment]
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kvm/vmx/tdx.c | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
index 271c2f94b8dd..37d088f6f7a8 100644
--- a/arch/x86/kvm/vmx/tdx.c
+++ b/arch/x86/kvm/vmx/tdx.c
@@ -2,6 +2,7 @@
 #include <linux/cleanup.h>
 #include <linux/cpu.h>
 #include <asm/cpufeature.h>
+#include <asm/cpuid/api.h>
 #include <asm/fpu/xcr.h>
 #include <linux/misc_cgroup.h>
 #include <linux/mmu_context.h>
@@ -163,12 +164,23 @@ static void td_init_cpuid_entry2(struct kvm_cpuid_entry2 *entry, unsigned char i
 
 	entry->function = (u32)td_conf->cpuid_config_leaves[idx];
 	entry->index = td_conf->cpuid_config_leaves[idx] >> 32;
+	entry->flags = 0;
 	entry->eax = (u32)td_conf->cpuid_config_values[idx][0];
 	entry->ebx = td_conf->cpuid_config_values[idx][0] >> 32;
 	entry->ecx = (u32)td_conf->cpuid_config_values[idx][1];
 	entry->edx = td_conf->cpuid_config_values[idx][1] >> 32;
 
-	if (entry->index == KVM_TDX_CPUID_NO_SUBLEAF)
+	WARN_ON_ONCE(cpuid_function_is_indexed(entry->function) !=
+		     (entry->index != KVM_TDX_CPUID_NO_SUBLEAF));
+
+	/*
+	 * Explicitly zero the index when it's not significant, even though it
+	 * _should_ be meaningless.  Userspace relies on the index being zero
+	 * (the ABI was inherited from KVM_GET_SUPPORTED_CPUID).
+	 */
+	if (cpuid_function_is_indexed(entry->function))
+		entry->flags |= KVM_CPUID_FLAG_SIGNIFCANT_INDEX;
+	else
 		entry->index = 0;
 
 	/*
-- 
2.56.0.257.gf7497c7d27-goog

[PATCH v2 3/3] KVM: TDX: Reject KVM_TDX_INIT_VM if indexed CPUID functions don't match

[Sean Christopherson]

Reject KVM_TDX_INIT_VM if userspace doesn't configure the canonical CPUID
entries correctly with respect to KVM_CPUID_FLAG_SIGNIFCANT_INDEX to fix a
bug where userspace could bypass the TSX and WAITPKG checks by simply not
marking a CPUID.0x7 entry as being indexed.  This also sets the stage for
more in-depth validation of the incoming CPUID configuration.

This is obviously an ABI change and diverges from KVM's general approach of
"let userspace do what it wants".  In practice, no "real" VMM that supports
TDX misconfigures a TD's CPUID entries in this way, i.e. the probability of
actually breaking userspace is basically nil.  And unlike normal VMs, where
KVM has full control and thus can deal with bizarre CPUID input without too
much fuss, TDX VMs require extra care due to the TDX Module also reacting
to the CPUID configuration, i.e. KVM_TDX_INIT_VM needs to be more strict
than KVM_SET_CPUID{,2} to avoid creating potentially dangerous-to-the-host
setups.

Opportunistically rename the helper to make it more obvious that it's
checking if the passed in @entry is unsupported, as opposed to returning a
set of unsupported entries or something.

Fixes: 6d415778f106 ("KVM: TDX: Disable support for TSX and WAITPKG")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/kvm/20260604024927.E22311F00893@smtp.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kvm/vmx/tdx.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
index 37d088f6f7a8..6abf92ffec24 100644
--- a/arch/x86/kvm/vmx/tdx.c
+++ b/arch/x86/kvm/vmx/tdx.c
@@ -151,8 +151,12 @@ static void tdx_clear_unsupported_cpuid(struct kvm_cpuid_entry2 *entry)
 		clear_waitpkg(entry);
 }
 
-static bool tdx_unsupported_cpuid(const struct kvm_cpuid_entry2 *entry)
+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);
 }
 
@@ -2393,7 +2397,7 @@ static int setup_tdparams_cpuids(struct kvm_cpuid2 *cpuid,
 		if (!entry)
 			continue;
 
-		if (tdx_unsupported_cpuid(entry))
+		if (tdx_is_unsupported_cpuid_entry(entry))
 			return -EINVAL;
 
 		copy_cnt++;
-- 
2.56.0.257.gf7497c7d27-goog

Re: [PATCH v2 0/3] x86/cpuid: KVM: TDX CPUID fixes

[Edgecombe, Rick P]

On Thu, 2026-10-22 at 14:01 -0700, Sean Christopherson wrote:
> Changyuan Lyu (1):
>   KVM: TDX: Set SIGNIFCANT_INDEX flag as appropriate when filling CPUID
>     entries
> 
> Sean Christopherson (2):
>   x86/cpuid: Mark CPUID function 0x23 as being indexed
>   KVM: TDX: Reject KVM_TDX_INIT_VM if indexed CPUID functions don't
>     match

Ran it through our automated tests:

Tested-by: Rick Edgecombe <rick.p.edgecombe@intel.com>

Re: [PATCH v2 0/3] x86/cpuid: KVM: TDX CPUID fixes

[Edgecombe, Rick P]

On Thu, 2026-10-22 at 18:25 -0700, Rick Edgecombe wrote:
> Ran it through our automated tests:
> 
> Tested-by: Rick Edgecombe <rick.p.edgecombe@intel.com>

And:

Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>

Re: [PATCH v2 2/3] KVM: TDX: Set SIGNIFCANT_INDEX flag as appropriate when filling CPUID entries

[Binbin Wu]

On 10/23/2026 5:01 AM, Sean Christopherson wrote:
> From: Changyuan Lyu <changyuanl@google.com>
> 
> Set the KVM_CPUID_FLAG_SIGNIFCANT_INDEX flag in the kvm_cpuid_entry2
> structures returned by KVM_TDX_CAPABILITIES if the CPUID is indexed,
> otherwise KVM could confuse userspace and induce a configuration error.
> This also ensures consistency with the CPUID entries returned by
> KVM_GET_SUPPORTED_CPUID.
> 
> WARN if KVM and the TDX Module don't align on which functions have
> significant indices, e.g. to help ensure the kernel is updated when the
> TDX Module learns about new CPUID leaves, and vice versa.
> 
> Opportunistically add a comment to call out that zeroing the index when it
> isn't significant is ABI that userspace relies on, e.g. QEMU looks for '0'
> instead of checking KVM_CPUID_FLAG_SIGNIFCANT_INDEX.
> 
> Fixes: 61bb28279623 ("KVM: TDX: Get system-wide info about TDX module on initialization")
> Cc: stable@vger.kernel.org
> Cc: Binbin Wu <binbin.wu@linux.intel.com>
> Suggested-by: Sean Christopherson <seanjc@google.com>
> Signed-off-by: Changyuan Lyu <changyuanl@google.com>
> [sean: keep the WARN, don't key off KVM_TDX_CPUID_NO_SUBLEAF, add comment]
> Signed-off-by: Sean Christopherson <seanjc@google.com>
> ---
>  arch/x86/kvm/vmx/tdx.c | 14 +++++++++++++-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
> index 271c2f94b8dd..37d088f6f7a8 100644
> --- a/arch/x86/kvm/vmx/tdx.c
> +++ b/arch/x86/kvm/vmx/tdx.c
> @@ -2,6 +2,7 @@
>  #include <linux/cleanup.h>
>  #include <linux/cpu.h>
>  #include <asm/cpufeature.h>
> +#include <asm/cpuid/api.h>
>  #include <asm/fpu/xcr.h>
>  #include <linux/misc_cgroup.h>
>  #include <linux/mmu_context.h>
> @@ -163,12 +164,23 @@ static void td_init_cpuid_entry2(struct kvm_cpuid_entry2 *entry, unsigned char i
>  
>  	entry->function = (u32)td_conf->cpuid_config_leaves[idx];
>  	entry->index = td_conf->cpuid_config_leaves[idx] >> 32;
> +	entry->flags = 0;
>  	entry->eax = (u32)td_conf->cpuid_config_values[idx][0];
>  	entry->ebx = td_conf->cpuid_config_values[idx][0] >> 32;
>  	entry->ecx = (u32)td_conf->cpuid_config_values[idx][1];
>  	entry->edx = td_conf->cpuid_config_values[idx][1] >> 32;
>  
> -	if (entry->index == KVM_TDX_CPUID_NO_SUBLEAF)
> +	WARN_ON_ONCE(cpuid_function_is_indexed(entry->function) !=
> +		     (entry->index != KVM_TDX_CPUID_NO_SUBLEAF));
> +
> +	/*
> +	 * Explicitly zero the index when it's not significant, even though it
> +	 * _should_ be meaningless.  Userspace relies on the index being zero
> +	 * (the ABI was inherited from KVM_GET_SUPPORTED_CPUID).
> +	 */
> +	if (cpuid_function_is_indexed(entry->function))

If the information about whether the entry is indexed mismatched, i.e. the
warning above fired, should we use the information from the TDX module as the
standard?

> +		entry->flags |= KVM_CPUID_FLAG_SIGNIFCANT_INDEX;
> +	else
>  		entry->index = 0;
>  
>  	/*

Re: [PATCH v2 3/3] KVM: TDX: Reject KVM_TDX_INIT_VM if indexed CPUID functions don't match

[Binbin Wu]

On 10/23/2026 5:01 AM, Sean Christopherson wrote:
> Reject KVM_TDX_INIT_VM if userspace doesn't configure the canonical CPUID
> entries correctly with respect to KVM_CPUID_FLAG_SIGNIFCANT_INDEX to fix a
> bug where userspace could bypass the TSX and WAITPKG checks by simply not
> marking a CPUID.0x7 entry as being indexed.  This also sets the stage for
> more in-depth validation of the incoming CPUID configuration.
> 
> This is obviously an ABI change and diverges from KVM's general approach of
> "let userspace do what it wants".  In practice, no "real" VMM that supports
> TDX misconfigures a TD's CPUID entries in this way, i.e. the probability of
> actually breaking userspace is basically nil.  And unlike normal VMs, where
> KVM has full control and thus can deal with bizarre CPUID input without too
> much fuss, TDX VMs require extra care due to the TDX Module also reacting
> to the CPUID configuration, i.e. KVM_TDX_INIT_VM needs to be more strict
> than KVM_SET_CPUID{,2} to avoid creating potentially dangerous-to-the-host
> setups.
> 
> Opportunistically rename the helper to make it more obvious that it's
> checking if the passed in @entry is unsupported, as opposed to returning a
> set of unsupported entries or something.
> 
> Fixes: 6d415778f106 ("KVM: TDX: Disable support for TSX and WAITPKG")
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Closes: https://lore.kernel.org/kvm/20260604024927.E22311F00893@smtp.kernel.org
> Cc: stable@vger.kernel.org
> Signed-off-by: Sean Christopherson <seanjc@google.com>
> ---
>  arch/x86/kvm/vmx/tdx.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
> index 37d088f6f7a8..6abf92ffec24 100644
> --- a/arch/x86/kvm/vmx/tdx.c
> +++ b/arch/x86/kvm/vmx/tdx.c
> @@ -151,8 +151,12 @@ static void tdx_clear_unsupported_cpuid(struct kvm_cpuid_entry2 *entry)
>  		clear_waitpkg(entry);
>  }
>  
> -static bool tdx_unsupported_cpuid(const struct kvm_cpuid_entry2 *entry)
> +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;

Similar to patch 2, if cpuid_function_is_indexed(entry->function) misses some function,
the value of cpuid_function_is_indexed(entry->function) is not accurate.

For current code, it's OK, since all unsupported bits are in leaf 7.
In the future, with the TDX CPUID validation patch set
https://lore.kernel.org/all/20261016091422.3182216-6-binbin.wu@linux.intel.com/
It still allow userspace to by pass some check in theory.
> +
>  	return has_tsx(entry) || has_waitpkg(entry);
>  }
>  
> @@ -2393,7 +2397,7 @@ static int setup_tdparams_cpuids(struct kvm_cpuid2 *cpuid,
>  		if (!entry)
>  			continue;
>  
> -		if (tdx_unsupported_cpuid(entry))
> +		if (tdx_is_unsupported_cpuid_entry(entry))
>  			return -EINVAL;
>  
>  		copy_cnt++;

Re: [PATCH v2 1/3] x86/cpuid: Mark CPUID function 0x23 as being indexed

[Xiaoyao Li]

On 10/23/2026 5:01 AM, Sean Christopherson wrote:
> Add function 0x23 to the set of CPUID functions that are indexed, as per
> the SDM and the many sub-leafs defined in leaf_types.h.
> 
> Reported-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Closes: https://lore.kernel.org/all/213d614fe73e183a230c8f4e0c8fa1cc3d45df39.camel@intel.com
> Cc: stable@vger.kernel.org
> Signed-off-by: Sean Christopherson <seanjc@google.com>

Reviewed-by: Xiaoyao Li <xiaoyao.li@Intel.com>

> ---
>  arch/x86/include/asm/cpuid/api.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/x86/include/asm/cpuid/api.h b/arch/x86/include/asm/cpuid/api.h
> index 82eddfa2347b..25b22b173f2a 100644
> --- a/arch/x86/include/asm/cpuid/api.h
> +++ b/arch/x86/include/asm/cpuid/api.h
> @@ -181,6 +181,7 @@ static __always_inline bool cpuid_function_is_indexed(u32 function)
>  	case 0x1d:
>  	case 0x1e:
>  	case 0x1f:
> +	case 0x23:
>  	case 0x24:
>  	case 0x8000001d:
>  		return true;

Re: [PATCH v2 3/3] KVM: TDX: Reject KVM_TDX_INIT_VM if indexed CPUID functions don't match

[Xiaoyao Li]

On 10/23/2026 11:05 AM, Binbin Wu wrote:
> On 10/23/2026 5:01 AM, Sean Christopherson wrote:
>> Reject KVM_TDX_INIT_VM if userspace doesn't configure the canonical CPUID
>> entries correctly with respect to KVM_CPUID_FLAG_SIGNIFCANT_INDEX to fix a
>> bug where userspace could bypass the TSX and WAITPKG checks by simply not
>> marking a CPUID.0x7 entry as being indexed.  This also sets the stage for
>> more in-depth validation of the incoming CPUID configuration.
>>
>> This is obviously an ABI change and diverges from KVM's general approach of
>> "let userspace do what it wants".  In practice, no "real" VMM that supports
>> TDX misconfigures a TD's CPUID entries in this way, i.e. the probability of
>> actually breaking userspace is basically nil.  And unlike normal VMs, where
>> KVM has full control and thus can deal with bizarre CPUID input without too
>> much fuss, TDX VMs require extra care due to the TDX Module also reacting
>> to the CPUID configuration, i.e. KVM_TDX_INIT_VM needs to be more strict
>> than KVM_SET_CPUID{,2} to avoid creating potentially dangerous-to-the-host
>> setups.
>>
>> Opportunistically rename the helper to make it more obvious that it's
>> checking if the passed in @entry is unsupported, as opposed to returning a
>> set of unsupported entries or something.
>>
>> Fixes: 6d415778f106 ("KVM: TDX: Disable support for TSX and WAITPKG")
>> Reported-by: Sashiko <sashiko-bot@kernel.org>
>> Closes: https://lore.kernel.org/kvm/20260604024927.E22311F00893@smtp.kernel.org
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Sean Christopherson <seanjc@google.com>
>> ---
>>  arch/x86/kvm/vmx/tdx.c | 8 ++++++--
>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
>> index 37d088f6f7a8..6abf92ffec24 100644
>> --- a/arch/x86/kvm/vmx/tdx.c
>> +++ b/arch/x86/kvm/vmx/tdx.c
>> @@ -151,8 +151,12 @@ static void tdx_clear_unsupported_cpuid(struct kvm_cpuid_entry2 *entry)
>>  		clear_waitpkg(entry);
>>  }
>>  
>> -static bool tdx_unsupported_cpuid(const struct kvm_cpuid_entry2 *entry)
>> +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;
> 
> Similar to patch 2, if cpuid_function_is_indexed(entry->function) misses some function,
> the value of cpuid_function_is_indexed(entry->function) is not accurate.
> 
> For current code, it's OK, since all unsupported bits are in leaf 7.
> In the future, with the TDX CPUID validation patch set
> https://lore.kernel.org/all/20261016091422.3182216-6-binbin.wu@linux.intel.com/
> It still allow userspace to by pass some check in theory.
some idea.

If we decide to honor TDX module's report over KVM's cpuid_function_is_indexed()
in patch2, then how about something below:

diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
index 6abf92ffec24..1456f4c5c6b3 100644
--- a/arch/x86/kvm/vmx/tdx.c
+++ b/arch/x86/kvm/vmx/tdx.c
@@ -151,10 +151,10 @@ static void tdx_clear_unsupported_cpuid(struct
kvm_cpuid_entry2 *entry)
                clear_waitpkg(entry);
 }

-static bool tdx_is_unsupported_cpuid_entry(const struct kvm_cpuid_entry2 *entry)
+static bool tdx_is_unsupported_cpuid_entry(const struct kvm_cpuid_entry2 *entry,
+                                          bool significant_index)
 {
-       if (cpuid_function_is_indexed(entry->function) !=
-           !!(entry->flags & KVM_CPUID_FLAG_SIGNIFCANT_INDEX))
+       if (significant_index && !(entry->flags & KVM_CPUID_FLAG_SIGNIFCANT_INDEX))
                return true;

        return has_tsx(entry) || has_waitpkg(entry);
@@ -2397,7 +2397,8 @@ static int setup_tdparams_cpuids(struct kvm_cpuid2 *cpuid,
                if (!entry)
                        continue;

-               if (tdx_is_unsupported_cpuid_entry(entry))
+               if (tdx_is_unsupported_cpuid_entry(entry,
+                       tmp->flags |= KVM_CPUID_FLAG_SIGNIFCANT_INDEX))
                        return -EINVAL;

                copy_cnt++;

Re: [PATCH v2 2/3] KVM: TDX: Set SIGNIFCANT_INDEX flag as appropriate when filling CPUID entries

[Sean Christopherson]

On Fri, Oct 23, 2026, Binbin Wu wrote:
> On 10/23/2026 5:01 AM, Sean Christopherson wrote:
> > diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
> > index 271c2f94b8dd..37d088f6f7a8 100644
> > --- a/arch/x86/kvm/vmx/tdx.c
> > +++ b/arch/x86/kvm/vmx/tdx.c
> > @@ -2,6 +2,7 @@
> >  #include <linux/cleanup.h>
> >  #include <linux/cpu.h>
> >  #include <asm/cpufeature.h>
> > +#include <asm/cpuid/api.h>
> >  #include <asm/fpu/xcr.h>
> >  #include <linux/misc_cgroup.h>
> >  #include <linux/mmu_context.h>
> > @@ -163,12 +164,23 @@ static void td_init_cpuid_entry2(struct kvm_cpuid_entry2 *entry, unsigned char i
> >  
> >  	entry->function = (u32)td_conf->cpuid_config_leaves[idx];
> >  	entry->index = td_conf->cpuid_config_leaves[idx] >> 32;
> > +	entry->flags = 0;
> >  	entry->eax = (u32)td_conf->cpuid_config_values[idx][0];
> >  	entry->ebx = td_conf->cpuid_config_values[idx][0] >> 32;
> >  	entry->ecx = (u32)td_conf->cpuid_config_values[idx][1];
> >  	entry->edx = td_conf->cpuid_config_values[idx][1] >> 32;
> >  
> > -	if (entry->index == KVM_TDX_CPUID_NO_SUBLEAF)
> > +	WARN_ON_ONCE(cpuid_function_is_indexed(entry->function) !=
> > +		     (entry->index != KVM_TDX_CPUID_NO_SUBLEAF));
> > +
> > +	/*
> > +	 * Explicitly zero the index when it's not significant, even though it
> > +	 * _should_ be meaningless.  Userspace relies on the index being zero
> > +	 * (the ABI was inherited from KVM_GET_SUPPORTED_CPUID).
> > +	 */
> > +	if (cpuid_function_is_indexed(entry->function))
> 
> If the information about whether the entry is indexed mismatched, i.e. the
> warning above fired, should we use the information from the TDX module as the
> standard?

IMO, no.  All of this information is available at module load.  If we want to
harden KVM (and we probably should), then we should apply these sanity checks
(or equivalents) during tdx_hardware_setup() and disable TDX if any of them fail.

Anything else is a hope and a prayer.

Re: [PATCH v2 2/3] KVM: TDX: Set SIGNIFCANT_INDEX flag as appropriate when filling CPUID entries

[Binbin Wu]

On 10/24/2026 10:03 AM, Sean Christopherson wrote:
> On Fri, Oct 23, 2026, Binbin Wu wrote:
>> On 10/23/2026 5:01 AM, Sean Christopherson wrote:
>>> diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
>>> index 271c2f94b8dd..37d088f6f7a8 100644
>>> --- a/arch/x86/kvm/vmx/tdx.c
>>> +++ b/arch/x86/kvm/vmx/tdx.c
>>> @@ -2,6 +2,7 @@
>>>  #include <linux/cleanup.h>
>>>  #include <linux/cpu.h>
>>>  #include <asm/cpufeature.h>
>>> +#include <asm/cpuid/api.h>
>>>  #include <asm/fpu/xcr.h>
>>>  #include <linux/misc_cgroup.h>
>>>  #include <linux/mmu_context.h>
>>> @@ -163,12 +164,23 @@ static void td_init_cpuid_entry2(struct kvm_cpuid_entry2 *entry, unsigned char i
>>>  
>>>  	entry->function = (u32)td_conf->cpuid_config_leaves[idx];
>>>  	entry->index = td_conf->cpuid_config_leaves[idx] >> 32;
>>> +	entry->flags = 0;
>>>  	entry->eax = (u32)td_conf->cpuid_config_values[idx][0];
>>>  	entry->ebx = td_conf->cpuid_config_values[idx][0] >> 32;
>>>  	entry->ecx = (u32)td_conf->cpuid_config_values[idx][1];
>>>  	entry->edx = td_conf->cpuid_config_values[idx][1] >> 32;
>>>  
>>> -	if (entry->index == KVM_TDX_CPUID_NO_SUBLEAF)
>>> +	WARN_ON_ONCE(cpuid_function_is_indexed(entry->function) !=
>>> +		     (entry->index != KVM_TDX_CPUID_NO_SUBLEAF));
>>> +
>>> +	/*
>>> +	 * Explicitly zero the index when it's not significant, even though it
>>> +	 * _should_ be meaningless.  Userspace relies on the index being zero
>>> +	 * (the ABI was inherited from KVM_GET_SUPPORTED_CPUID).
>>> +	 */
>>> +	if (cpuid_function_is_indexed(entry->function))
>>
>> If the information about whether the entry is indexed mismatched, i.e. the
>> warning above fired, should we use the information from the TDX module as the
>> standard?
> 
> IMO, no.  All of this information is available at module load.  If we want to
> harden KVM (and we probably should), then we should apply these sanity checks
> (or equivalents) during tdx_hardware_setup() and disable TDX if any of them fail.

OK.

In practice, I don't think it is a problem unless cpuid_function_is_indexed() is
missing an indexed leaf that KVM cares about.  If it isn't missing one, unknown
CPUID leafs will still be rejected later by the allowlist-based TDX CPUID
validation.

There is also a false-positive risk: a new TDX module could report an indexed
leaf that KVM doesn't know about. One way to avoid that is for KVM to fail TDX
module initialization only when there is a mismatch *and* the leaf is listed in
reverse_cpuid[]. I think that can be handled separately.

I'll rebase my TDX CPUID validation patch series on top of this series.

> 
> Anything else is a hope and a prayer.

Re: [PATCH v2 0/3] x86/cpuid: KVM: TDX CPUID fixes

[Binbin Wu]

On 10/23/2026 5:01 AM, Sean Christopherson wrote:
> 
> Changyuan Lyu (1):
>   KVM: TDX: Set SIGNIFCANT_INDEX flag as appropriate when filling CPUID
>     entries
> 
> Sean Christopherson (2):
>   x86/cpuid: Mark CPUID function 0x23 as being indexed
>   KVM: TDX: Reject KVM_TDX_INIT_VM if indexed CPUID functions don't
>     match

Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com>

Re: [PATCH v2 2/3] KVM: TDX: Set SIGNIFCANT_INDEX flag as appropriate when filling CPUID entries

[Xiaoyao Li]

On 10/23/2026 5:01 AM, Sean Christopherson wrote:
> From: Changyuan Lyu <changyuanl@google.com>
> 
> Set the KVM_CPUID_FLAG_SIGNIFCANT_INDEX flag in the kvm_cpuid_entry2
> structures returned by KVM_TDX_CAPABILITIES if the CPUID is indexed,
> otherwise KVM could confuse userspace and induce a configuration error.
> This also ensures consistency with the CPUID entries returned by
> KVM_GET_SUPPORTED_CPUID.
> 
> WARN if KVM and the TDX Module don't align on which functions have
> significant indices, e.g. to help ensure the kernel is updated when the
> TDX Module learns about new CPUID leaves, and vice versa.
> 
> Opportunistically add a comment to call out that zeroing the index when it
> isn't significant is ABI that userspace relies on, e.g. QEMU looks for '0'
> instead of checking KVM_CPUID_FLAG_SIGNIFCANT_INDEX.
> 
> Fixes: 61bb28279623 ("KVM: TDX: Get system-wide info about TDX module on initialization")
> Cc: stable@vger.kernel.org
> Cc: Binbin Wu <binbin.wu@linux.intel.com>
> Suggested-by: Sean Christopherson <seanjc@google.com>
> Signed-off-by: Changyuan Lyu <changyuanl@google.com>
> [sean: keep the WARN, don't key off KVM_TDX_CPUID_NO_SUBLEAF, add comment]
> Signed-off-by: Sean Christopherson <seanjc@google.com>
> ---
>  arch/x86/kvm/vmx/tdx.c | 14 +++++++++++++-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
> index 271c2f94b8dd..37d088f6f7a8 100644
> --- a/arch/x86/kvm/vmx/tdx.c
> +++ b/arch/x86/kvm/vmx/tdx.c
> @@ -2,6 +2,7 @@
>  #include <linux/cleanup.h>
>  #include <linux/cpu.h>
>  #include <asm/cpufeature.h>
> +#include <asm/cpuid/api.h>
>  #include <asm/fpu/xcr.h>
>  #include <linux/misc_cgroup.h>
>  #include <linux/mmu_context.h>
> @@ -163,12 +164,23 @@ static void td_init_cpuid_entry2(struct kvm_cpuid_entry2 *entry, unsigned char i
>  
>  	entry->function = (u32)td_conf->cpuid_config_leaves[idx];
>  	entry->index = td_conf->cpuid_config_leaves[idx] >> 32;
> +	entry->flags = 0;
>  	entry->eax = (u32)td_conf->cpuid_config_values[idx][0];
>  	entry->ebx = td_conf->cpuid_config_values[idx][0] >> 32;
>  	entry->ecx = (u32)td_conf->cpuid_config_values[idx][1];
>  	entry->edx = td_conf->cpuid_config_values[idx][1] >> 32;
>  
> -	if (entry->index == KVM_TDX_CPUID_NO_SUBLEAF)
> +	WARN_ON_ONCE(cpuid_function_is_indexed(entry->function) !=
> +		     (entry->index != KVM_TDX_CPUID_NO_SUBLEAF));

I think the WARN_ON_ONCE() is very likely to be triggered in the future when
people run old kernel with new TDX modules.

> +	/*
> +	 * Explicitly zero the index when it's not significant, even though it
> +	 * _should_ be meaningless.  Userspace relies on the index being zero
> +	 * (the ABI was inherited from KVM_GET_SUPPORTED_CPUID).
> +	 */
> +	if (cpuid_function_is_indexed(entry->function))
> +		entry->flags |= KVM_CPUID_FLAG_SIGNIFCANT_INDEX;
> +	else
>  		entry->index = 0;
>  
>  	/*

Re: [PATCH v2 2/3] KVM: TDX: Set SIGNIFCANT_INDEX flag as appropriate when filling CPUID entries

[Sean Christopherson]

On Tue, Oct 27, 2026, Xiaoyao Li wrote:
> On 10/23/2026 5:01 AM, Sean Christopherson wrote:
> > diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
> > index 271c2f94b8dd..37d088f6f7a8 100644
> > --- a/arch/x86/kvm/vmx/tdx.c
> > +++ b/arch/x86/kvm/vmx/tdx.c
> > @@ -2,6 +2,7 @@
> >  #include <linux/cleanup.h>
> >  #include <linux/cpu.h>
> >  #include <asm/cpufeature.h>
> > +#include <asm/cpuid/api.h>
> >  #include <asm/fpu/xcr.h>
> >  #include <linux/misc_cgroup.h>
> >  #include <linux/mmu_context.h>
> > @@ -163,12 +164,23 @@ static void td_init_cpuid_entry2(struct kvm_cpuid_entry2 *entry, unsigned char i
> >  
> >  	entry->function = (u32)td_conf->cpuid_config_leaves[idx];
> >  	entry->index = td_conf->cpuid_config_leaves[idx] >> 32;
> > +	entry->flags = 0;
> >  	entry->eax = (u32)td_conf->cpuid_config_values[idx][0];
> >  	entry->ebx = td_conf->cpuid_config_values[idx][0] >> 32;
> >  	entry->ecx = (u32)td_conf->cpuid_config_values[idx][1];
> >  	entry->edx = td_conf->cpuid_config_values[idx][1] >> 32;
> >  
> > -	if (entry->index == KVM_TDX_CPUID_NO_SUBLEAF)
> > +	WARN_ON_ONCE(cpuid_function_is_indexed(entry->function) !=
> > +		     (entry->index != KVM_TDX_CPUID_NO_SUBLEAF));
> 
> I think the WARN_ON_ONCE() is very likely to be triggered in the future when
> people run old kernel with new TDX modules.

Then upstream patches to make that not happen.  Intel insists on treating the TDX
Module like hardware.  So, treat new TDX Modules like new hardware.  Upstream
support for the new "hardware" before it ships, cc'd to stable@vger.kernel.org
if necessary.

Because IMO, the WARN is doing exactly what it's intended to do: alerting the
admin that they are running a potentially dangerous setup.

> > +	/*
> > +	 * Explicitly zero the index when it's not significant, even though it
> > +	 * _should_ be meaningless.  Userspace relies on the index being zero
> > +	 * (the ABI was inherited from KVM_GET_SUPPORTED_CPUID).
> > +	 */
> > +	if (cpuid_function_is_indexed(entry->function))
> > +		entry->flags |= KVM_CPUID_FLAG_SIGNIFCANT_INDEX;
> > +	else
> >  		entry->index = 0;
> >  
> >  	/*
> 
> 

Re: [PATCH v2 2/3] KVM: TDX: Set SIGNIFCANT_INDEX flag as appropriate when filling CPUID entries

[Xiaoyao Li]

On 10/27/2026 10:05 PM, Sean Christopherson wrote:
> On Tue, Oct 27, 2026, Xiaoyao Li wrote:
>> On 10/23/2026 5:01 AM, Sean Christopherson wrote:
>>> diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
>>> index 271c2f94b8dd..37d088f6f7a8 100644
>>> --- a/arch/x86/kvm/vmx/tdx.c
>>> +++ b/arch/x86/kvm/vmx/tdx.c
>>> @@ -2,6 +2,7 @@
>>>  #include <linux/cleanup.h>
>>>  #include <linux/cpu.h>
>>>  #include <asm/cpufeature.h>
>>> +#include <asm/cpuid/api.h>
>>>  #include <asm/fpu/xcr.h>
>>>  #include <linux/misc_cgroup.h>
>>>  #include <linux/mmu_context.h>
>>> @@ -163,12 +164,23 @@ static void td_init_cpuid_entry2(struct kvm_cpuid_entry2 *entry, unsigned char i
>>>  
>>>  	entry->function = (u32)td_conf->cpuid_config_leaves[idx];
>>>  	entry->index = td_conf->cpuid_config_leaves[idx] >> 32;
>>> +	entry->flags = 0;
>>>  	entry->eax = (u32)td_conf->cpuid_config_values[idx][0];
>>>  	entry->ebx = td_conf->cpuid_config_values[idx][0] >> 32;
>>>  	entry->ecx = (u32)td_conf->cpuid_config_values[idx][1];
>>>  	entry->edx = td_conf->cpuid_config_values[idx][1] >> 32;
>>>  
>>> -	if (entry->index == KVM_TDX_CPUID_NO_SUBLEAF)
>>> +	WARN_ON_ONCE(cpuid_function_is_indexed(entry->function) !=
>>> +		     (entry->index != KVM_TDX_CPUID_NO_SUBLEAF));
>>
>> I think the WARN_ON_ONCE() is very likely to be triggered in the future when
>> people run old kernel with new TDX modules.
> 
> Then upstream patches to make that not happen.  Intel insists on treating the TDX
> Module like hardware.  So, treat new TDX Modules like new hardware.  Upstream
> support for the new "hardware" before it ships, cc'd to stable@vger.kernel.org
> if necessary.
> 
> Because IMO, the WARN is doing exactly what it's intended to do: alerting the
> admin that they are running a potentially dangerous setup.

For this specific case, does it mean every later patch to add a new leaf in
cpuid_function_is_indexed() needs to be backported to stable?

Re: [PATCH v2 2/3] KVM: TDX: Set SIGNIFCANT_INDEX flag as appropriate when filling CPUID entries

[Sean Christopherson]

On Tue, Oct 27, 2026, Xiaoyao Li wrote:
> On 10/27/2026 10:05 PM, Sean Christopherson wrote:
> > On Tue, Oct 27, 2026, Xiaoyao Li wrote:
> >> On 10/23/2026 5:01 AM, Sean Christopherson wrote:
> >>> diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
> >>> index 271c2f94b8dd..37d088f6f7a8 100644
> >>> --- a/arch/x86/kvm/vmx/tdx.c
> >>> +++ b/arch/x86/kvm/vmx/tdx.c
> >>> @@ -2,6 +2,7 @@
> >>>  #include <linux/cleanup.h>
> >>>  #include <linux/cpu.h>
> >>>  #include <asm/cpufeature.h>
> >>> +#include <asm/cpuid/api.h>
> >>>  #include <asm/fpu/xcr.h>
> >>>  #include <linux/misc_cgroup.h>
> >>>  #include <linux/mmu_context.h>
> >>> @@ -163,12 +164,23 @@ static void td_init_cpuid_entry2(struct kvm_cpuid_entry2 *entry, unsigned char i
> >>>  
> >>>  	entry->function = (u32)td_conf->cpuid_config_leaves[idx];
> >>>  	entry->index = td_conf->cpuid_config_leaves[idx] >> 32;
> >>> +	entry->flags = 0;
> >>>  	entry->eax = (u32)td_conf->cpuid_config_values[idx][0];
> >>>  	entry->ebx = td_conf->cpuid_config_values[idx][0] >> 32;
> >>>  	entry->ecx = (u32)td_conf->cpuid_config_values[idx][1];
> >>>  	entry->edx = td_conf->cpuid_config_values[idx][1] >> 32;
> >>>  
> >>> -	if (entry->index == KVM_TDX_CPUID_NO_SUBLEAF)
> >>> +	WARN_ON_ONCE(cpuid_function_is_indexed(entry->function) !=
> >>> +		     (entry->index != KVM_TDX_CPUID_NO_SUBLEAF));
> >>
> >> I think the WARN_ON_ONCE() is very likely to be triggered in the future when
> >> people run old kernel with new TDX modules.
> > 
> > Then upstream patches to make that not happen.  Intel insists on treating the TDX
> > Module like hardware.  So, treat new TDX Modules like new hardware.  Upstream
> > support for the new "hardware" before it ships, cc'd to stable@vger.kernel.org
> > if necessary.
> > 
> > Because IMO, the WARN is doing exactly what it's intended to do: alerting the
> > admin that they are running a potentially dangerous setup.
> 
> For this specific case, does it mean every later patch to add a new leaf in
> cpuid_function_is_indexed() needs to be backported to stable?

If you want to ship a new TDX Module that enumerates features in those leaves and
works as-is on older kernels, yes.  Again, this isn't really any different than
enabling new hardware.  E.g. a kernel from 2024 generally doesn't work flawlessly
on a CPU being released in 2026.