On Tue, Oct 06, 2026 at 08:20:56AM +0000, Dragos Tarcatu wrote:
> rte_cpu_get_flag_enabled() reads only the CPUID feature bits. CPUID
> tells what the CPU implements, not what the OS enables. If the OS does
> not enable the related state components in XCR0, the first AVX or AVX512
> instruction raises #UD.
>
> CPUID can report AVX512 while XCR0 has no AVX512 state. Old kernels
> without AVX512 state support leave XCR0 at 0x7. A kernel booted with
> clearcpuid=avx512f removes the AVX512 state from XCR0, but CPUID still
> reports AVX512F. Similarly, gather_data_sampling=force removes the AVX
> state.
>
> On such a system, the rte_net_crc constructor selects the AVX512 code
> from CPUID alone. The dynamic loader runs this constructor before main(),
> so the application gets SIGILL before EAL can parse any argument.
>
> For the AVX-class and AVX512-class flags, also read XCR0 with XGETBV.
> Report the flag only when the OS has enabled the related state. Use
> XGETBV only when CPUID reports OSXSAVE, because the instruction faults
> otherwise.
>
> This change also affects rte_cpu_is_supported(). If DPDK is built for
> AVX512 and the OS does not enable AVX512 state, EAL can now stop with an
> error that names the missing flag. This is possible only if no AVX512
> instruction executes before rte_eal_init(), for example in a constructor.
>
> Fixes: 3934bb741354 ("eal/x86: identify AVX512 CPU flag") Cc:
> [email protected]
>
> Signed-off-by: Dragos Tarcatu <[email protected]> ---
> lib/eal/include/generic/rte_cpuflags.h | 3 + lib/eal/x86/rte_cpuflags.c
> | 102 ++++++++++++++++++++----- 2 files changed, 86 insertions(+), 19
> deletions(-)
>
Tested this using two "x86-generic" builds from test-meson-builds.sh, one
with this patch and one without. The test app from the one without the
patch gives illegal instruction on an initializer for avx512 crc, while the
one with runs successfully.
Code looks correct to me also.
Tested-by: Bruce Richardson <[email protected]>
Acked-by: Bruce Richardson <[email protected]>
