/proc/cpuinfo 的 flags 仅反映 CPU 硬件能力，不表示内核或用户态已启用对应指令集加速；真正生效需满足微码更新、内核配置开启、相关模块加载（如 aesni_intel）及用户态库主动调用等多重条件。
gcc -march=native 能看到的只是编译时支持的指令集，不是运行时启用状态
不少人通过 gcc -march=native -Q --help=target | grep march 查到 march=skylake 后，便误以为A VX-512或BMI2已启用。实际上，这仅仅是GCC依据CPUID检测出的“硬件支持”情况，并不意味着内核或用户空间已激活相应的加速路径。真正对是否启用硬件加速起决定作用的，是内核配置、CPU微码版本，以及具体子系统（如crypto、crypto API、KVM）是否加载了对应的模块。
/proc/cpuinfo 的 flags 字段只反映硬件能力，不反映内核运行时开关
cat /proc/cpuinfo | grep flags 输出的 a vx a vx2 a vx512f bmi1 bmi2 fma 等，全是 CPUID.0x00000001:EDX / 0x00000007:EBX 等寄存器原始位，属于静态能力通告。即使内核启动时禁用了某项功能（例如通过 noa vx 内核参数），flags 依然会显示它 —— 因为那是 CPU 告诉 BIOS/UEFI 的，不是内核告诉用户的。
- 验证方法：加
noa vx启动后执行cat /proc/cpuinfo | grep a vx，仍会输出a vx a vx2 - 真正失效的是使用 A VX 寄存器的代码段：触发 #UD 异常，或被内核 trap 后降级执行
- 关键判断点应落在实际子系统行为，而非
flags是否存在
查 crypto API 加速模块是否启用（最常见需求场景）
多数人关心指令集加速，其实是想知道 AES-NI、SHA-NI、GHASH 等密码运算是否走硬件路径。Linux 内核通过 crypto 子系统暴露接口，可用以下命令确认：
- 列出当前所有已注册的 crypto 算法及其驱动：
cat /proc/crypto | grep -A 5 -B 5 "module|driver|async" - 检查 AES-NI 是否被 crypto API 选中：
grep -r "aesni" /lib/modules/$(uname -r)/kernel/arch/x86/crypto/ 2>/dev/null，再看对应模块是否 loaded：lsmod | grep aesni - 强制测试：运行
openssl speed -evp aes-128-gcm，若输出中type显示aes-128-gcm且数值远高于软件实现（如 >5 GB/s），基本可判定 AES-NI 生效
注意：某些发行版（如 RHEL/CentOS 7）默认未启用 aesni_intel 模块，需手动 modprobe aesni_intel 并加入 /etc/modules-load.d/crypto.conf。
查内核启动日志里有没有明确禁用或 fallback 提示
内核在初始化 CPU 特性时会打印关键决策，比如是否跳过 A VX 恢复、是否因微码缺陷屏蔽某扩展：
- 搜索典型提示：
dmesg | grep -i -E "(a vx|bmi|xsa ve|fpu|microcode|disabled|fallback)" - 重点看类似这样的行：
A VX2 version of ghash-clmulni not a vailable, using generic version（说明硬件 GHASH 未启用） - 或：
microcode: updated early microcode to revision 0x28, date = 2024-04-12—— 若 revision 过旧，某些新指令（如 A VX-512 ERMSB）可能被内核主动规避
真正排查起来困难的，是微码、内核patch以及用户态库（像OpenSSL、libsodium）这三者之间存在的隐式兼容断层。比如说，CPU是支持A VX - 512的，然而微码却没有更新，内核也没有加载与intel_rapl_msr相关的补丁，同时OpenSSL又默认关闭了A VX - 512路径——在这种情况下，所有的命令都显示“支持”，可实际上加速根本就不会发生。
