CPU支持虚拟化需同时满足硬件标志、BIOS启用、内核模块加载及/dev/kvm可用；仅grep vmx/svm有输出不等于可运行KVM，常见断点在BIOS关闭、模块未加载或Secure Boot阻止。
能直接用命令查，但单看 CPU 标志不等于真能跑虚拟机——必须连 BIOS 状态、内核模块、设备节点一起验证。
grep -E "vmx|svm" /proc/cpuinfo 有输出就代表支持？
不一定。这个命令只说明 CPU 硬件具备 vmx（Intel VT-x）或 svm（AMD-V）能力，但常见断点在 BIOS 层：很多服务器出厂默认关闭虚拟化，即使 CPU 原生支持，/proc/cpuinfo 里也查不到对应 flag。
- 如果命令无输出，先别急着换机器，进 BIOS 找
Intel Virtualization Technology或SVM Mode并设为Enabled - 某些低功耗 Intel CPU（如 J 系列）或老 Atom 芯片确实不支持
vmx，BIOS 开了也没用 - 云服务器（如 AWS t3）可能返回
vmx，但 Hypervisor 已劫持指令，/dev/kvm依然不可用——这是平台限制，非配置问题
kvm-ok 报 “KVM acceleration can NOT be used” 怎么定位？
kvm-ok 是闭环验证工具，它同时检查三件事：vmx/svm 标志、kvm_intel 或 kvm_amd 模块是否加载、/dev/kvm 设备节点是否存在。报错时按顺序排查：
- 运行
lsmod | grep kvm：没输出说明模块没加载，尝试sudo modprobe kvm_intel（Intel）或sudo modprobe kvm_amd（AMD） - 运行
ls -l /dev/kvm：若提示No such file or directory，是模块加载失败或 Secure Boot 阻止了模块（可临时禁用测试） - 非 root 用户跑 QEMU 会权限不足：需执行
sudo usermod -aG kvm $USER，然后重新登录
为什么 lscpu 显示 “Virtualization: VT-x”，但 qemu-system-x86_64 还报 “KVM acceleration not available”？
lscpu 只是解析 /proc/cpuinfo，它告诉你“CPU 有这个能力”，不保证当前环境可用。真实阻断点常藏在中间层：
- BIOS 设置被重置（尤其 OEM 主板，恢复默认会关掉虚拟化）
- 宿主机本身跑在 VMware/VirtualBox 里，而外层未开启
Nested VT-x（嵌套虚拟化） - 内核启动参数含
nosmt或mitigations=off等，个别组合会影响 KVM 初始化 - 某些主板启用
VT-d（IOMMU）后反而导致kvm_intel加载失败，可尝试关闭 VT-d 单独测试
真正关键的不是“CPU 支持什么”，而是“当前系统能否拿到 /dev/kvm 并让普通用户访问”。跳过 kvm-ok 直接上 QEMU，很容易卡在静默失败上——比如进程不报错但退回到软件模拟模式，性能暴跌却难以察觉。
