[PATCH v2] KVM: x86: Remove AMX-TF32 enumeration

[PATCH v2] KVM: x86: Remove AMX-TF32 enumeration

[Chang S. Bae]

AMX-TF32 enumeration was added based on the Intel documentation [1]. The
recent update removed the feature, indicating that the feature is no
longer planned for hardware implementation.

[1] Intel Architecture Instruction Set Extensions and Future Features

Note: The feature first appeared in the September 2025 revision of the
document and was removed in the June 2026 revision.

Cc: stable@vger.kernel.org # v6.20+
Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com>
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
---
V1 -> V2: Collect tags (Zhao, Binbin), put note (Binbu), and cc @stable
---
 arch/x86/kvm/cpuid.c         | 1 -
 arch/x86/kvm/reverse_cpuid.h | 1 -
 2 files changed, 2 deletions(-)

diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 591d2294acd7..759a1c557080 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -1082,7 +1082,6 @@ void kvm_initialize_cpu_caps(void)
 		F(AMX_COMPLEX_ALIAS),
 		F(AMX_FP16_ALIAS),
 		F(AMX_FP8),
-		F(AMX_TF32),
 		F(AMX_AVX512),
 		F(AMX_MOVRS),
 	);
diff --git a/arch/x86/kvm/reverse_cpuid.h b/arch/x86/kvm/reverse_cpuid.h
index 2ad25781cefb..1bb13903c5b2 100644
--- a/arch/x86/kvm/reverse_cpuid.h
+++ b/arch/x86/kvm/reverse_cpuid.h
@@ -56,7 +56,6 @@
 #define X86_FEATURE_AMX_COMPLEX_ALIAS	KVM_X86_FEATURE(CPUID_1E_1_EAX, 2)
 #define X86_FEATURE_AMX_FP16_ALIAS	KVM_X86_FEATURE(CPUID_1E_1_EAX, 3)
 #define X86_FEATURE_AMX_FP8		KVM_X86_FEATURE(CPUID_1E_1_EAX, 4)
-#define X86_FEATURE_AMX_TF32		KVM_X86_FEATURE(CPUID_1E_1_EAX, 6)
 #define X86_FEATURE_AMX_AVX512		KVM_X86_FEATURE(CPUID_1E_1_EAX, 7)
 #define X86_FEATURE_AMX_MOVRS		KVM_X86_FEATURE(CPUID_1E_1_EAX, 8)
 
-- 
2.53.0

Re: [PATCH v2] KVM: x86: Remove AMX-TF32 enumeration

[Xiaoyao Li]

On 7/21/2026 4:52 AM, Chang S. Bae wrote:
> AMX-TF32 enumeration was added based on the Intel documentation [1]. The
> recent update removed the feature, indicating that the feature is no
> longer planned for hardware implementation.
> 
> [1] Intel Architecture Instruction Set Extensions and Future Features
> 
> Note: The feature first appeared in the September 2025 revision of the
> document and was removed in the June 2026 revision.

The feature was first introduced in revision 054, October 2024.

It's recorded in the revision history.

> Cc: stable@vger.kernel.org # v6.20+
> Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com>
> Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>

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

> ---
> V1 -> V2: Collect tags (Zhao, Binbin), put note (Binbu), and cc @stable
> ---
>   arch/x86/kvm/cpuid.c         | 1 -
>   arch/x86/kvm/reverse_cpuid.h | 1 -
>   2 files changed, 2 deletions(-)
> 
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index 591d2294acd7..759a1c557080 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -1082,7 +1082,6 @@ void kvm_initialize_cpu_caps(void)
>   		F(AMX_COMPLEX_ALIAS),
>   		F(AMX_FP16_ALIAS),
>   		F(AMX_FP8),
> -		F(AMX_TF32),
>   		F(AMX_AVX512),
>   		F(AMX_MOVRS),
>   	);
> diff --git a/arch/x86/kvm/reverse_cpuid.h b/arch/x86/kvm/reverse_cpuid.h
> index 2ad25781cefb..1bb13903c5b2 100644
> --- a/arch/x86/kvm/reverse_cpuid.h
> +++ b/arch/x86/kvm/reverse_cpuid.h
> @@ -56,7 +56,6 @@
>   #define X86_FEATURE_AMX_COMPLEX_ALIAS	KVM_X86_FEATURE(CPUID_1E_1_EAX, 2)
>   #define X86_FEATURE_AMX_FP16_ALIAS	KVM_X86_FEATURE(CPUID_1E_1_EAX, 3)
>   #define X86_FEATURE_AMX_FP8		KVM_X86_FEATURE(CPUID_1E_1_EAX, 4)
> -#define X86_FEATURE_AMX_TF32		KVM_X86_FEATURE(CPUID_1E_1_EAX, 6)
>   #define X86_FEATURE_AMX_AVX512		KVM_X86_FEATURE(CPUID_1E_1_EAX, 7)
>   #define X86_FEATURE_AMX_MOVRS		KVM_X86_FEATURE(CPUID_1E_1_EAX, 8)
>   

Re: [PATCH v2] KVM: x86: Remove AMX-TF32 enumeration

[Sean Christopherson]

On Mon, Jul 20, 2026, Chang S. Bae wrote:
> AMX-TF32 enumeration was added based on the Intel documentation [1]. The
> recent update removed the feature, indicating that the feature is no
> longer planned for hardware implementation.
> 
> [1] Intel Architecture Instruction Set Extensions and Future Features
> 
> Note: The feature first appeared in the September 2025 revision of the
> document and was removed in the June 2026 revision.
> 
> Cc: stable@vger.kernel.org # v6.20+

6.20 isn't a thing.  And given that this is clearly associated with a specific
commit, just do:

  Fixes: 58cbaf64e653 ("KVM: x86: Advertise AMX CPUIDs in subleaf 0x1E.0x1 to userspace")

and let script magic sort out the rest.  No need for another version, if we
agree that ripping out support is the way to go, I'll fixup when applying.

> Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com>
> Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
> ---
> V1 -> V2: Collect tags (Zhao, Binbin), put note (Binbu), and cc @stable
> ---
>  arch/x86/kvm/cpuid.c         | 1 -
>  arch/x86/kvm/reverse_cpuid.h | 1 -
>  2 files changed, 2 deletions(-)
> 
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index 591d2294acd7..759a1c557080 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -1082,7 +1082,6 @@ void kvm_initialize_cpu_caps(void)
>  		F(AMX_COMPLEX_ALIAS),
>  		F(AMX_FP16_ALIAS),
>  		F(AMX_FP8),
> -		F(AMX_TF32),
>  		F(AMX_AVX512),
>  		F(AMX_MOVRS),
>  	);
> diff --git a/arch/x86/kvm/reverse_cpuid.h b/arch/x86/kvm/reverse_cpuid.h
> index 2ad25781cefb..1bb13903c5b2 100644
> --- a/arch/x86/kvm/reverse_cpuid.h
> +++ b/arch/x86/kvm/reverse_cpuid.h
> @@ -56,7 +56,6 @@
>  #define X86_FEATURE_AMX_COMPLEX_ALIAS	KVM_X86_FEATURE(CPUID_1E_1_EAX, 2)
>  #define X86_FEATURE_AMX_FP16_ALIAS	KVM_X86_FEATURE(CPUID_1E_1_EAX, 3)
>  #define X86_FEATURE_AMX_FP8		KVM_X86_FEATURE(CPUID_1E_1_EAX, 4)
> -#define X86_FEATURE_AMX_TF32		KVM_X86_FEATURE(CPUID_1E_1_EAX, 6)

I'm not convinced that yanking out support is the right move.  By publishing the
feature, for several years, Intel pretty much burned that CPUID bit.  E.g. it's
not impossible that someone other than Intel has implemented TF32 instructions.

The opcodes are fair game in the future, because their use can be qualified and
guarded, but the same doesn't hold true for enumeration.  E.g. similar to how
MPX got ripped out and its XSTATE assets got reused for APX, but the CPUID feature
enumeration is forever reserved for MPX (I hope).

If the argument is that "Intel Architecture Instruction Set Extensions and Future
Features" isn't binding documentation, i.e. that Intel can do take backs until a
feature is documented in the SDM, then I honestly don't see any option but to
refuse to accept new features until they land in the SDM.  Which I don't think
any of us want.

>  #define X86_FEATURE_AMX_AVX512		KVM_X86_FEATURE(CPUID_1E_1_EAX, 7)
>  #define X86_FEATURE_AMX_MOVRS		KVM_X86_FEATURE(CPUID_1E_1_EAX, 8)
>  
> -- 
> 2.53.0
> 

Re: [PATCH v2] KVM: x86: Remove AMX-TF32 enumeration

[Chang S. Bae]

On 7/23/2026 11:04 AM, Sean Christopherson wrote:
> 
> I'm not convinced that yanking out support is the right move.  By publishing the
> feature, for several years, Intel pretty much burned that CPUID bit.  E.g. it's
> not impossible that someone other than Intel has implemented TF32 instructions.
> 
> The opcodes are fair game in the future, because their use can be qualified and
> guarded, but the same doesn't hold true for enumeration.  E.g. similar to how
> MPX got ripped out and its XSTATE assets got reused for APX, but the CPUID feature
> enumeration is forever reserved for MPX (I hope).
> 
> If the argument is that "Intel Architecture Instruction Set Extensions and Future
> Features" isn't binding documentation, i.e. that Intel can do take backs until a
> feature is documented in the SDM, then I honestly don't see any option but to
> refuse to accept new features until they land in the SDM.  Which I don't think
> any of us want.
One distinction I could think of is whether a feature ever ships in 
implementations. If a feature is actually implemented and is later 
deprecated or removed, then I agree the bit should remain reserved. That 
appears quite clear.

My understanding is that the revert was considered because TF32 never 
reached any implementation. If that's incorrect, I'd certainly welcome a 
correction. But if it holds true, then I also want to clarify the case 
is different from retiring a feature that was already in products.

That said though, I think you made a point. If new features are 
published there, we add support based on that, and are later asked to 
remove the support, it becomes harder to convince what level of 
stability the ISE doc can provide.

I don't think these decisions are made lightly. We humans may sometimes 
reconsider features before they ever ship. But cases like this 
inevitably damage the credibility. If this happens repeatedly, it 
becomes increasingly reasonable to take a more conservative approach -- 
perhaps even until there is hardware implementation at hand.

I'd relay this feedback to the relevant folks, as I do think this is an 
important point to consider. I'll cc you.

Thanks,
Chang

Re: [PATCH v2] KVM: x86: Remove AMX-TF32 enumeration

[Christian Ludloff]

> My understanding is that the revert was considered because TF32 never
> reached any implementation. If that's incorrect, I'd certainly welcome a
> correction.

Both TF32 and TRANSPOSE made it into a product that shipped.

Not from Intel... but.

So their CPUID feature flags and their opcodes aren't reclaimable
and efforts to rip out their software support are counterproductive.

That is all I can say.

--
C.

Re: [PATCH v2] KVM: x86: Remove AMX-TF32 enumeration

[Sean Christopherson]

On Thu, Jul 23, 2026, Chang S. Bae wrote:
> On 7/23/2026 11:04 AM, Sean Christopherson wrote:
> > 
> > I'm not convinced that yanking out support is the right move.  By publishing the
> > feature, for several years, Intel pretty much burned that CPUID bit.  E.g. it's
> > not impossible that someone other than Intel has implemented TF32 instructions.
> > 
> > The opcodes are fair game in the future, because their use can be qualified and
> > guarded, but the same doesn't hold true for enumeration.  E.g. similar to how
> > MPX got ripped out and its XSTATE assets got reused for APX, but the CPUID feature
> > enumeration is forever reserved for MPX (I hope).
> > 
> > If the argument is that "Intel Architecture Instruction Set Extensions and Future
> > Features" isn't binding documentation, i.e. that Intel can do take backs until a
> > feature is documented in the SDM, then I honestly don't see any option but to
> > refuse to accept new features until they land in the SDM.  Which I don't think
> > any of us want.
> One distinction I could think of is whether a feature ever ships in
> implementations. If a feature is actually implemented and is later
> deprecated or removed, then I agree the bit should remain reserved. That
> appears quite clear.

Per Christian, who's mail client apparently doesn't use In-Reply-To and breaks
threading for me and lore, TF32 made it into a shipped product[*].

So "officially", NAK.

[*] https://lore.kernel.org/all/CAKSQd8V%3DwfVrUxeU%2BfDRgKJBLdiyCkkY2SRY%2BOoRBNE68LFnCg@mail.gmail.com

Re: [PATCH v2] KVM: x86: Remove AMX-TF32 enumeration

[Dave Hansen]

On 7/24/26 08:37, Christian Ludloff wrote:
>> My understanding is that the revert was considered because TF32 never
>> reached any implementation. If that's incorrect, I'd certainly welcome a
>> correction.
> Both TF32 and TRANSPOSE made it into a product that shipped.
> 
> Not from Intel... but.
> 
> So their CPUID feature flags and their opcodes aren't reclaimable
> and efforts to rip out their software support are counterproductive.

What would folks' preference be on how Intel should document this going
forward? Just leave it as it as enumerating TF32?

There are notes in the SDM like:

	Intel® MPX has been deprecated and will not be available on any
	future processors.

There could be a note like that for the TF32, I would imagine.

Re: [PATCH v2] KVM: x86: Remove AMX-TF32 enumeration

[Christian Ludloff]

On Tue, Aug 18, 2026 at 5:55 PM Dave Hansen <dave.hansen@intel.com> wrote:
> On 7/24/26 08:37, Christian Ludloff wrote:
> >> My understanding is that the revert was considered because TF32 never
> >> reached any implementation. If that's incorrect, I'd certainly welcome a
> >> correction.
> > Both TF32 and TRANSPOSE made it into a product that shipped.
> >
> > Not from Intel... but.
> >
> > So their CPUID feature flags and their opcodes aren't reclaimable
> > and efforts to rip out their software support are counterproductive.
>
> What would folks' preference be on how Intel should document this going
> forward? Just leave it as it as enumerating TF32?
>
> There are notes in the SDM like:
>
>         Intel® MPX has been deprecated and will not be available on any
>         future processors.
>
> There could be a note like that for the TF32, I would imagine.

Yes, that terse sentence works.
  Once for AMX-TRANSPOSE.
  Once for AMX-TF32.

If you want the back references:
  TRANSPOSE got dropped from ISE #059 and APX #007.
  TF32 got dropped from ISE #062.

In terms of the opcodes, it is like MPX too: no recycling for
a long time. Luckily there is plenty of remaining space.

--
C.

Re: [PATCH v2] KVM: x86: Remove AMX-TF32 enumeration

[Sean Christopherson]

On Tue, Aug 18, 2026, Christian Ludloff wrote:
> On Tue, Aug 18, 2026 at 5:55 PM Dave Hansen <dave.hansen@intel.com> wrote:
> > On 7/24/26 08:37, Christian Ludloff wrote:
> > >> My understanding is that the revert was considered because TF32 never
> > >> reached any implementation. If that's incorrect, I'd certainly welcome a
> > >> correction.
> > > Both TF32 and TRANSPOSE made it into a product that shipped.
> > >
> > > Not from Intel... but.
> > >
> > > So their CPUID feature flags and their opcodes aren't reclaimable
> > > and efforts to rip out their software support are counterproductive.
> >
> > What would folks' preference be on how Intel should document this going
> > forward? Just leave it as it as enumerating TF32?
> >
> > There are notes in the SDM like:
> >
> >         Intel® MPX has been deprecated and will not be available on any
> >         future processors.
> >
> > There could be a note like that for the TF32, I would imagine.
> 
> Yes, that terse sentence works.
>   Once for AMX-TRANSPOSE.
>   Once for AMX-TF32.

Maybe use a similar approach as is done for the HYPERVISOR bit (0x1.ECX[31), and
have the "Field Name" entry say Not Used, and then use the "Description" to explain
why?  E.g.

  Register        Field Name      Description                             Domain
  EAX[6]          Not Used        Intel processors always return 0.       Platform
                                  Allocated for backwards compatibility
                                  with software that expects this to
                                  enumerate AMX_TF32.

Or Christian's terse version (I kinda like the terse version).

  Register        Field Name      Description                             Domain
  EAX[6]          Not Used        Intel processors always return 0.       Platform
                                  Once for AMX_TF32.

 
> If you want the back references:
>   TRANSPOSE got dropped from ISE #059 and APX #007.
>   TF32 got dropped from ISE #062.
> 
> In terms of the opcodes, it is like MPX too: no recycling for
> a long time. Luckily there is plenty of remaining space.
> 
> --
> C.