qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2] i386/cpu: Remove FEAT_24_0_EBX for AVX10
@ 2025-07-07 14:11 Xiaoyao Li
  2025-07-08  8:46 ` Zhao Liu
                   ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Xiaoyao Li @ 2025-07-07 14:11 UTC (permalink / raw)
  To: Paolo Bonzini; +Cc: qemu-devel, Zhao Liu, tao1.su, chenyi.qiang, xiaoyao.li

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)
-- 
2.43.0



^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH v2] i386/cpu: Remove FEAT_24_0_EBX for AVX10
  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
  2025-09-12 10:46 ` Zhao Liu
  2 siblings, 0 replies; 5+ messages in thread
From: Zhao Liu @ 2025-07-08  8:46 UTC (permalink / raw)
  To: Xiaoyao Li; +Cc: Paolo Bonzini, qemu-devel, tao1.su, chenyi.qiang

On Mon, Jul 07, 2025 at 10:11:51PM +0800, Xiaoyao Li wrote:
> Date: Mon, 7 Jul 2025 22:11:51 +0800
> From: Xiaoyao Li <xiaoyao.li@intel.com>
> Subject: [PATCH v2] i386/cpu: Remove FEAT_24_0_EBX for AVX10
> X-Mailer: git-send-email 2.43.0
> 
> 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(-)

LGTM,

Reviewed-by: Zhao Liu <zhao1.liu@intel.com>



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH v2] i386/cpu: Remove FEAT_24_0_EBX for AVX10
  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
  2025-09-12 10:46 ` Zhao Liu
  2 siblings, 0 replies; 5+ messages in thread
From: Xiaoyao Li @ 2025-09-12  5:44 UTC (permalink / raw)
  To: Paolo Bonzini; +Cc: qemu-devel, Zhao Liu, tao1.su, chenyi.qiang

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)



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH v2] i386/cpu: Remove FEAT_24_0_EBX for AVX10
  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
@ 2025-09-12 10:46 ` Zhao Liu
  2025-09-15  8:24   ` Xiaoyao Li
  2 siblings, 1 reply; 5+ messages in thread
From: Zhao Liu @ 2025-09-12 10:46 UTC (permalink / raw)
  To: Xiaoyao Li; +Cc: Paolo Bonzini, qemu-devel, tao1.su, chenyi.qiang

Hi Xiaoyao,

Rethinking this patch, I would not remove these feature bits with the
comments inline:

> 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,
> -    },

"Reserved at 1" means always enabling, not being deprecated.

So if someone has already cofigured "+avx10-128,+avx10-256,+avx10-512"
for his cpu, this patch will break his use.

Although explicitly setting AVX10 vector length feature bits appears
uncommon, but explicitly masking off these feature bits is even more
unusual.

Removing these bits has little benefit but brings the risk of breaking
the API.

In the future, QEMU may need the AVX10 model to handle different
versions. A complete feature list is necessary. This is another reason.

In addition, I also agree with KVM's point to keep these feature names:

https://lore.kernel.org/kvm/Zkz5Ak0PQlAN8DxK@google.com/

...

> @@ -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;

Hardcoding is not friendly for maintenance, and they are essentially
feature bits.

>          }
>          break;
>      }

Thanks,
Zhao



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH v2] i386/cpu: Remove FEAT_24_0_EBX for AVX10
  2025-09-12 10:46 ` Zhao Liu
@ 2025-09-15  8:24   ` Xiaoyao Li
  0 siblings, 0 replies; 5+ messages in thread
From: Xiaoyao Li @ 2025-09-15  8:24 UTC (permalink / raw)
  To: Zhao Liu; +Cc: Paolo Bonzini, qemu-devel, tao1.su, chenyi.qiang

On 9/12/2025 6:46 PM, Zhao Liu wrote:
> Hi Xiaoyao,
> 
> Rethinking this patch, I would not remove these feature bits with the
> comments inline:
> 
>> 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,
>> -    },
> 
> "Reserved at 1" means always enabling, not being deprecated.
> 
> So if someone has already cofigured "+avx10-128,+avx10-256,+avx10-512"
> for his cpu, this patch will break his use.
> 
> Although explicitly setting AVX10 vector length feature bits appears
> uncommon, but explicitly masking off these feature bits is even more
> unusual.
> 
> Removing these bits has little benefit but brings the risk of breaking
> the API.

I cannot argue against the risk of breaking the API.

Can we go the process to deprecate them?

> In the future, QEMU may need the AVX10 model to handle different
> versions. A complete feature list is necessary. This is another reason.

But whatever the avx10 version is/ will be, all the vector lengths will 
be supported. This is fundamental to AVX10.

Keeping the avx10-{128,256,512} feature bits in QEMU, misleads users to 
think they are configurable and they can do fancy thing to create a 
virtual hardware that only supports a subset of vector length for AVX10 
while the truth is they cannot.

> In addition, I also agree with KVM's point to keep these feature names:
> 
> https://lore.kernel.org/kvm/Zkz5Ak0PQlAN8DxK@google.com/

Could you elaborate what point from Sean from the link suggesting to 
keep these feature names?

> ...
> 
>> @@ -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;
> 
> Hardcoding is not friendly for maintenance, and they are essentially
> feature bits.
> 
>>           }
>>           break;
>>       }
> 
> Thanks,
> Zhao
> 



^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2025-09-15  8:26 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2025-09-12 10:46 ` Zhao Liu
2025-09-15  8:24   ` Xiaoyao Li

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).