From: Xiaoyao Li <xiaoyao.li@intel.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org, Zhao Liu <zhao1.liu@intel.com>,
tao1.su@intel.com, chenyi.qiang@intel.com
Subject: Re: [PATCH v2] i386/cpu: Remove FEAT_24_0_EBX for AVX10
Date: Fri, 12 Sep 2025 13:44:58 +0800 [thread overview]
Message-ID: <c878ee60-9e7e-4a14-9bf6-e7331196af82@intel.com> (raw)
In-Reply-To: <20250707141151.4187798-1-xiaoyao.li@intel.com>
Gentle Ping.
On 7/7/2025 10:11 PM, Xiaoyao Li wrote:
> It turns out that all the Intel processors enumerating the support of
> Intel AVX10 support all vector widths. It's documented in the latest
> SDM, vol 1, Chapter 16 "programming with Intel AVX10".
>
> (Note that AVX10.1 spec stops update since AVX10 is subsumed into SDM
> while AVX10.2 spec stays update for the future extension of AVX10)
>
> Now SDM [1] marks the bit 16-18 of CPUID.0x24_0.EBX as reserved and they
> are reserved at 1. The purpose of Intel is to remove the semantic of
> vector length enumeration from these bits since all the 128/256/512 bit
> length are supported and no need for enumeration. But Intel has to keep
> them reserved at 1 to make it compatible with the software written based
> on earlier avx10 spec that checks the bits to query of the support of each
> vector length.
>
> For QEMU, it makes no sense to allow the configurability of the bits
> anymore. Remove the leaf FEAT_24_0_EBX and related stuff. Just hardcore
> the bits to all 1 when AVX10 is exposed to guest, to comply with the SDM
> and stop trying to associate them with the enumeration of vector length.
>
> [1] https://cdrdv2.intel.com/v1/dl/getContent/671200 (rev 088)
>
> Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com>
> ---
> changes in v2:
> - refine the commit message to reference update from SDM instead of
> AVX10 spec;
> - call out explicitly the purpose of disassociating the enumeration of
> vector length from the CPUID bits.
> ---
> target/i386/cpu.c | 37 ++-----------------------------------
> target/i386/cpu.h | 12 ------------
> 2 files changed, 2 insertions(+), 47 deletions(-)
>
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 0d35e95430fe..1b50fd4e397d 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -912,7 +912,6 @@ void x86_cpu_vendor_words2str(char *dst, uint32_t vendor1,
> #define TCG_SGX_12_0_EAX_FEATURES 0
> #define TCG_SGX_12_0_EBX_FEATURES 0
> #define TCG_SGX_12_1_EAX_FEATURES 0
> -#define TCG_24_0_EBX_FEATURES 0
>
> #if defined CONFIG_USER_ONLY
> #define CPUID_8000_0008_EBX_KERNEL_FEATURES (CPUID_8000_0008_EBX_IBPB | \
> @@ -1208,20 +1207,6 @@ FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
> },
> .tcg_features = TCG_7_2_EDX_FEATURES,
> },
> - [FEAT_24_0_EBX] = {
> - .type = CPUID_FEATURE_WORD,
> - .feat_names = {
> - [16] = "avx10-128",
> - [17] = "avx10-256",
> - [18] = "avx10-512",
> - },
> - .cpuid = {
> - .eax = 0x24,
> - .needs_ecx = true, .ecx = 0,
> - .reg = R_EBX,
> - },
> - .tcg_features = TCG_24_0_EBX_FEATURES,
> - },
> [FEAT_8000_0007_EDX] = {
> .type = CPUID_FEATURE_WORD,
> .feat_names = {
> @@ -1839,22 +1824,6 @@ static FeatureDep feature_dependencies[] = {
> .from = { FEAT_7_0_EBX, CPUID_7_0_EBX_SGX },
> .to = { FEAT_SGX_12_1_EAX, ~0ull },
> },
> - {
> - .from = { FEAT_24_0_EBX, CPUID_24_0_EBX_AVX10_128 },
> - .to = { FEAT_24_0_EBX, CPUID_24_0_EBX_AVX10_256 },
> - },
> - {
> - .from = { FEAT_24_0_EBX, CPUID_24_0_EBX_AVX10_256 },
> - .to = { FEAT_24_0_EBX, CPUID_24_0_EBX_AVX10_512 },
> - },
> - {
> - .from = { FEAT_24_0_EBX, CPUID_24_0_EBX_AVX10_VL_MASK },
> - .to = { FEAT_7_1_EDX, CPUID_7_1_EDX_AVX10 },
> - },
> - {
> - .from = { FEAT_7_1_EDX, CPUID_7_1_EDX_AVX10 },
> - .to = { FEAT_24_0_EBX, ~0ull },
> - },
> };
>
> typedef struct X86RegisterInfo32 {
> @@ -4732,9 +4701,6 @@ static const X86CPUDefinition builtin_x86_defs[] = {
> { "movdiri", "on" },
> { "movdir64b", "on" },
> { "avx10", "on" },
> - { "avx10-128", "on" },
> - { "avx10-256", "on" },
> - { "avx10-512", "on" },
> { "avx10-version", "1" },
> { "stepping", "1" },
> { /* end of list */ }
> @@ -7720,7 +7686,8 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
> *ecx = 0;
> *edx = 0;
> if ((env->features[FEAT_7_1_EDX] & CPUID_7_1_EDX_AVX10) && count == 0) {
> - *ebx = env->features[FEAT_24_0_EBX] | env->avx10_version;
> + /* bit 16-18 are reserved at 1 */
> + *ebx = (0x7U << 16) | env->avx10_version;
> }
> break;
> }
> diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> index 51e10139dfdf..7856a882f014 100644
> --- a/target/i386/cpu.h
> +++ b/target/i386/cpu.h
> @@ -671,7 +671,6 @@ typedef enum FeatureWord {
> FEAT_7_1_ECX, /* CPUID[EAX=7,ECX=1].ECX */
> FEAT_7_1_EDX, /* CPUID[EAX=7,ECX=1].EDX */
> FEAT_7_2_EDX, /* CPUID[EAX=7,ECX=2].EDX */
> - FEAT_24_0_EBX, /* CPUID[EAX=0x24,ECX=0].EBX */
> FEATURE_WORDS,
> } FeatureWord;
>
> @@ -1037,17 +1036,6 @@ uint64_t x86_cpu_get_supported_feature_word(X86CPU *cpu, FeatureWord w);
> /* Packets which contain IP payload have LIP values */
> #define CPUID_14_0_ECX_LIP (1U << 31)
>
> -/* AVX10 128-bit vector support is present */
> -#define CPUID_24_0_EBX_AVX10_128 (1U << 16)
> -/* AVX10 256-bit vector support is present */
> -#define CPUID_24_0_EBX_AVX10_256 (1U << 17)
> -/* AVX10 512-bit vector support is present */
> -#define CPUID_24_0_EBX_AVX10_512 (1U << 18)
> -/* AVX10 vector length support mask */
> -#define CPUID_24_0_EBX_AVX10_VL_MASK (CPUID_24_0_EBX_AVX10_128 | \
> - CPUID_24_0_EBX_AVX10_256 | \
> - CPUID_24_0_EBX_AVX10_512)
> -
> /* RAS Features */
> #define CPUID_8000_0007_EBX_OVERFLOW_RECOV (1U << 0)
> #define CPUID_8000_0007_EBX_SUCCOR (1U << 1)
next prev parent reply other threads:[~2025-09-12 5:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-07 14:11 [PATCH v2] i386/cpu: Remove FEAT_24_0_EBX for AVX10 Xiaoyao Li
2025-07-08 8:46 ` Zhao Liu
2025-09-12 5:44 ` Xiaoyao Li [this message]
2025-09-12 10:46 ` Zhao Liu
2025-09-15 8:24 ` Xiaoyao Li
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=c878ee60-9e7e-4a14-9bf6-e7331196af82@intel.com \
--to=xiaoyao.li@intel.com \
--cc=chenyi.qiang@intel.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=tao1.su@intel.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.