On Wed, 7 Oct 2026 at 15:01, Bruce Richardson <[email protected]> wrote: > > 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]> --- > Tested-by: Bruce Richardson <[email protected]> > Acked-by: Bruce Richardson <[email protected]>
Applied, thanks. -- David Marchand
