Re: [PATCH v4 00.9/16] x86/CPUID: enable AVX10 leaf

[Jan Beulich <jbeulich@xxxxxxxx>]

On 10.04.2026 11:26, Teddy Astie wrote:
> Le 09/04/2026 à 17:18, Jan Beulich a écrit :
>> This requires bumping the number of basic leaves we support. Apart from
>> this the logic is modeled as closely as possible after that of leaf 7
>> handling.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> ---
>> The gen-cpuid.py adjustment is merely the minimum needed. It's not
>> really clear to me whether someone turning off e.g. AVX512BW might then
>> also validly expect AVX10 to be turned off.
> 
> AFAIUI, AVX512BW is a dependency of AVX10, as AVX10 implies that the 
> former is available.

I'm not convinced it is a "dependency". My understanding is that while
Intel may say that all their AVX10 hardware is expected to set all the
respective AVX512* bits as well, the spec says e.g. "Intel® AVX-512
instruction families included in Intel® AVX10.1 are shown in Table 3.2."
Where "instruction families" doesn't say anything about CPUID bits. So
from an abstract spec pov someone wanting to use e.g. VMOVDQU8 will
want to check for AVX10 || AVX512BW.

>> Do we want to synthesize AVX10 in the (max?) policies when all necessary
>> AVX512* features are available, thus allowing migration from an AVX10
>> host to a suitable non-AVX10 one?
> 
> I guess we want, there is not really a reason to not allow it.
> 
> Some software may check for AVX10 only, and not check for individual 
> AVX512 bits.

As per above, such software may be slightly flawed. Synthesizing the
AVX10 feature bit also means synthesizing the AVX10 leaf then, for
example. This may be somewhat of an issue for migration; I didn't
thoroughly think this through yet.

>> --- a/xen/arch/x86/cpu-policy.c
>> +++ b/xen/arch/x86/cpu-policy.c
>> @@ -211,7 +211,7 @@ static void recalculate_xstate(struct cp
>>       if ( p->feat.mpx )
>>           xstates |= X86_XCR0_BNDREGS | X86_XCR0_BNDCSR;
>>   
>> -    if ( p->feat.avx512f )
>> +    if ( p->feat.avx512f || p->feat.avx10 )
> 
> In principle, the avx10 check is redundant as avx512f must be set if 
> avx10 is set.

I don't think so; see above discussion of AVX512BW.

>> --- a/xen/arch/x86/lib/cpu-policy/cpuid.c
>> +++ b/xen/arch/x86/lib/cpu-policy/cpuid.c
>> @@ -125,6 +125,7 @@ void x86_cpu_policy_fill_native(struct c
>>           switch ( i )
>>           {
>>           case 0x4: case 0x7: case 0xb: case 0xd:
>> +        case 0x24:
>>               /* Multi-invocation leaves.  Deferred. */
>>               continue;
>>           }
>> @@ -218,6 +219,15 @@ void x86_cpu_policy_fill_native(struct c
>>           }
>>       }
>>   
>> +    if ( p->basic.max_leaf >= 0x24 )
>> +    {
>> +        cpuid_count_leaf(0x24, 0, &p->avx10.raw[0]);
>> +
>> +        for ( i = 1; i <= MIN(p->avx10.max_subleaf,
>> +                              ARRAY_SIZE(p->avx10.raw) - 1); ++i )
>> +            cpuid_count_leaf(0x24, i, &p->avx10.raw[i]);
> 
> Do we need to split the 0 iteration out ? I guess we can just start from 
> i = 0 instead.

Well, strictly formally p->avx10.max_subleaf is uninitialized on the
first loop iteration. Hence comparing against it isn't a good idea. (In
practice the field taking whatever value will let i == 0 pass, but still.)

What's more important though: I want to keep this in sync with what we to
elsewhere in the function.

>> --- a/xen/include/xen/lib/x86/cpu-policy.h
>> +++ b/xen/include/xen/lib/x86/cpu-policy.h
>> @@ -59,11 +59,12 @@ unsigned int x86_cpuid_lookup_vendor(uin
>>    */
>>   const char *x86_cpuid_vendor_to_str(unsigned int vendor);
>>   
>> -#define CPUID_GUEST_NR_BASIC      (0xdu + 1)
>> +#define CPUID_GUEST_NR_BASIC      (0x24u + 1)
>>   #define CPUID_GUEST_NR_CACHE      (5u + 1)
>>   #define CPUID_GUEST_NR_FEAT       (2u + 1)
>>   #define CPUID_GUEST_NR_TOPO       (1u + 1)
>>   #define CPUID_GUEST_NR_XSTATE     (62u + 1)
>> +#define CPUID_GUEST_NR_AVX10      (0u + 1)
> 
> Intel specification now defines AVX10.2 which has a additional leaf 
> (even though the whole leaf is currently marked as "reserved").

See "x86/CPUID: enable AVX10.2 sub-leaf" later in the series. The first
part aims at supporting just AVX10.1.

>> --- a/xen/tools/gen-cpuid.py
>> +++ b/xen/tools/gen-cpuid.py
>> @@ -294,7 +294,7 @@ def crunch_numbers(state):
>>           # enabled.  Certain later extensions, acting on 256-bit vectors of
>>           # integers, better depend on AVX2 than AVX.
>>           AVX2: [AVX512F, VAES, VPCLMULQDQ, AVX_VNNI, AVX_IFMA, 
>> AVX_VNNI_INT8,
>> -               AVX_VNNI_INT16, SHA512, SM4],
>> +               AVX_VNNI_INT16, SHA512, SM4, AVX10],
>>   
> 
> I think we can instead make AVX10 a dependency on AVX512. Especially since
> 
>  > Any processor that enumerates support for Intel AVX10 will also 
> enumerate support for Intel AVX, Intel AVX2, and Intel AVX-512 (see 
> Table 16-2).
> 
> with AVX-512 depending on AVX2.

That's the very statement I refer to at the top. Intel may say this for
themselves, but the spec - according to my reading - doesn't mandate this.

Jan