KVM可用需CPU标志存在、BIOS开启且/dev/kvm可访问三者齐备；查/proc/cpuinfo中vmx或svm仅确认硬件支持，不保证KVM可用。
能直接查到 vmx 或 svm，不代表 KVM 就能用；必须三者齐备：CPU 标志存在 + BIOS 开启 + /dev/kvm 可访问。
查 /proc/cpuinfo 里有没有 vmx 或 svm
这是最底层、最可靠的硬件能力信号。但注意：没输出 ≠ 硬件不支持，大概率是 BIOS 关着。
- 只看 Intel：
grep -m1 flags /proc/cpuinfo | grep -o vmx—— 有输出说明 CPU 原生支持 VT-x - 只看 AMD：
grep -m1 flags /proc/cpuinfo | grep -o svm—— 有输出说明 CPU 原生支持 AMD-V - 别用
cat /proc/cpuinfo | grep flags然后肉眼扫，flags 字段太长，容易漏；grep -o能精准剥离关键词 - 某些低功耗 Intel CPU（如 J 系列、老 Atom）压根没
vmx指令，即使 BIOS 开了也查不到
为什么 lscpu 显示 “Virtualization: VT-x” 却跑不了 KVM？
lscpu 只是解析 /proc/cpuinfo，它不验证当前环境是否可用。常见断点在中间层：
- BIOS 设置没保存，或重启后被 OEM 主板默认恢复为关闭
- 宿主机本身运行在 VMware/VirtualBox 里，而外层没开 Nested VT-x/AMD-V
-
lsmod | grep kvm没输出 —— 内核模块没加载：sudo modprobe kvm_intel（Intel）或sudo modprobe kvm_amd（AMD） - Secure Boot 启用时可能拒绝加载
kvm_intel，报Operation not permitted，可临时禁用测试
用 kvm-ok 做闭环验证
这是 Ubuntu/Debian 系统上最省心的验证方式，它一次性检查标志位、模块、设备节点三者。
- 先装工具：
sudo apt-get install cpu-checker - 再运行：
sudo kvm-ok - 成功输出含
INFO: /dev/kvm exists. KVM acceleration can be used才算真正可用 - 如果提示
KVM acceleration can NOT be used，别急着换 CPU，优先去 BIOS 翻找Intel Virtualization Technology或SVM Mode并设为Enabled - 非 root 用户跑 QEMU 还得加组：
sudo usermod -aG kvm $USER，然后重新登录才生效
云服务器上 vmx 存在但 /dev/kvm 缺失？
这不是配置问题，是平台限制。AWS EC2 t2/t3、阿里云部分共享型实例等，虽然 CPU 支持 vmx，但 Hypervisor 层已截获该指令，/dev/kvm 设备节点根本不会创建。这种情况下，kvm-ok 必定失败，任何 BIOS 或内核操作都无效。
