/proc/cpuinfo 的 flags 仅反映 CPU 硬件能力，不表示内核或用户态已启用对应指令集加速；真正生效需满足微码更新、内核配置开启、相关模块加载（如 aesni_intel）及用户态库主动调用等多重条件。
gcc -march=native 能看到的只是编译时支持的指令集，不是运行时启用状态
很多人用 gcc -march=native -Q --help=target | grep march 查到 march=skylake 就以为 AVX-512 或 BMI2 已启用，其实这只是 GCC 根据 CPUID 检测出“硬件支持”，不代表内核或用户空间已激活对应加速路径。真正决定是否启用硬件加速的，是内核配置、CPU 微码版本、以及具体子系统（如 crypto、crypto API、KVM）是否加载了对应模块。
/proc/cpuinfo 的 flags 字段只反映硬件能力，不反映内核运行时开关
cat /proc/cpuinfo | grep flags 输出的 avx avx2 avx512f bmi1 bmi2 fma 等，全是 CPUID.0x00000001:EDX / 0x00000007:EBX 等寄存器原始位，属于静态能力通告。即使内核启动时禁用了某项功能（例如通过 noavx 内核参数），flags 依然会显示它 —— 因为那是 CPU 告诉 BIOS/UEFI 的，不是内核告诉用户的。
- 验证方法：加
noavx启动后执行cat /proc/cpuinfo | grep avx，仍会输出avx avx2 - 真正失效的是使用 AVX 寄存器的代码段：触发 #UD 异常，或被内核 trap 后降级执行
- 关键判断点应落在实际子系统行为，而非
flags是否存在
查 crypto API 加速模块是否启用（最常见需求场景）
多数人关心指令集加速，其实是想知道 AES-NI、SHA-NI、GHASH 等密码运算是否走硬件路径。Linux 内核通过 crypto 子系统暴露接口，可用以下命令确认：
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- 列出当前所有已注册的 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 特性时会打印关键决策，比如是否跳过 AVX 恢复、是否因微码缺陷屏蔽某扩展：
- 搜索典型提示：
dmesg | grep -i -E "(avx|bmi|xsave|fpu|microcode|disabled|fallback)" - 重点看类似这样的行：
AVX2 version of ghash-clmulni not available, using generic version（说明硬件 GHASH 未启用） - 或：
microcode: updated early microcode to revision 0x28, date = 2023-04-12—— 若 revision 过旧，某些新指令（如 AVX-512 ERMSB）可能被内核主动规避
真正难排查的，是微码 + 内核 patch + 用户态库（如 OpenSSL、libsodium）三者之间的隐式兼容断层。比如 CPU 支持 AVX-512，但微码没更新，内核没加载 intel_rapl_msr 相关补丁，OpenSSL 又默认关闭 AVX-512 路径 —— 此时所有命令都显示“支持”，但加速根本不会发生。
