From: Sean Christopherson <seanjc@google.com>
To: "Chang S. Bae" <chang.seok.bae@intel.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
pbonzini@redhat.com, stable@vger.kernel.org,
Zhao Liu <zhao1.liu@intel.com>,
Binbin Wu <binbin.wu@linux.intel.com>
Subject: Re: [PATCH v2] KVM: x86: Remove AMX-TF32 enumeration
Date: Thu, 23 Jul 2026 11:04:33 -0700 [thread overview]
Message-ID: <amJXsVGv3xe7GKu1@google.com> (raw)
In-Reply-To: <20260720205208.519622-1-chang.seok.bae@intel.com>
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
>
next prev parent reply other threads:[~2026-07-23 18:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-20 20:52 [PATCH v2] KVM: x86: Remove AMX-TF32 enumeration Chang S. Bae
2026-07-21 0:37 ` Xiaoyao Li
2026-07-23 18:04 ` Sean Christopherson [this message]
2026-07-23 19:44 ` Chang S. Bae
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=amJXsVGv3xe7GKu1@google.com \
--to=seanjc@google.com \
--cc=binbin.wu@linux.intel.com \
--cc=chang.seok.bae@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=stable@vger.kernel.org \
--cc=zhao1.liu@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox