CPU支持硬件虚拟化当且仅当调用__cpuid(0x00000001)后cpu_info[2]的bit5为1；需先检测此位，为0则不支持，后续检测无需进行。
如何用 __cpuid 检测 CPU 是否支持硬件虚拟化（Intel VT-x / AMD-V）
直接看 ECX 寄存器第 5 位（bit 5）：为 1 表示 CPU 硬件层面支持虚拟化扩展。这是所有后续检测的前提，不满足就不用往下查了。
调用 __cpuid 时传入 0x00000001，Windows 和主流 Linux 的 MSVC/GCC/Clang 都支持该内建函数：
int cpu_info[4] = {0};
__cpuid(cpu_info, 0x00000001);
bool has_hv_support = (cpu_info[2] & (1 << 5)) != 0; // ECX[5]
注意：__cpuid 是用户态可执行指令，但仅反映 CPU 能力，不说明当前是否启用、是否被 Hypervisor 拦截或屏蔽。
- 某些 BIOS/UEFI 默认关闭 VT-x 或 SVM，需手动开启才能让该位生效
- 在 VMware Workstation 或 VirtualBox 中，即使宿主机支持，客户机的
__cpuid返回值可能被 Hypervisor 修改（例如隐藏该位） - ARM 架构不适用此方法；
__cpuid仅用于 x86/x64
怎么判断当前运行在 Hypervisor 之上（而非裸金属）
核心是检查 ECX 第 31 位（bit 31），它由 CPUID leaf 0x80000001 定义，官方名称为 HYPERVISOR_PRESENT。该位为 1，表示 CPU 正在 Hypervisor 控制下运行（无论是否启用嵌套虚拟化）。
立即学习“C++免费学习笔记（深入）”；
但要注意：该标志由 Hypervisor 主动设置，不是 CPU 自动置位。现代主流 Hypervisor（KVM、Hyper-V、VMware、Xen）均会设置它；而老版本 VirtualBox（
int hv_info[4] = {0};
__cpuid(hv_info, 0x80000001);
bool is_under_hypervisor = (hv_info[2] & (1U << 31)) != 0; // ECX[31]
- 必须先确认 CPU 支持扩展功能集（
0x80000000返回的最大扩展 leaf ≥0x80000001），否则读0x80000001可能返回全 0 - 某些固件（如 Apple Silicon 的 Rosetta 2 环境）不走 x86 CPUID 路径，此法完全失效
- 该检测无法区分 Hypervisor 类型，只回答“是不是”
如何识别具体是哪种 Hypervisor（VMware / Hyper-V / KVM 等）
当 is_under_hypervisor 为 true 后，进一步读取 vendor 字符串：调用 __cpuid with 0x40000000，其 EBX:ECX:EDX 组成 12 字节 ASCII 字符串（EAX 还含最大子叶号）。
不同 Hypervisor 填充不同签名：
- VMware：返回
"VMwareVMware" - Hyper-V：返回
"Microsoft Hv"（注意末尾空格） - KVM：返回
"KVMKVMKVM\0\0\0" - Xen：返回
"XenVMMXenVMM"
示例代码片段：
int hv_vendor[4] = {0};
__cpuid(hv_vendor, 0x40000000);
char sig[13] = {0};
memcpy(sig, &hv_vendor[1], 4); // EBX
memcpy(sig + 4, &hv_vendor[2], 4); // ECX
memcpy(sig + 8, &hv_vendor[3], 4); // EDX
// sig 现在是 12 字节 vendor 字符串，可 strcmp
关键限制：
-
0x40000000是 Hypervisor 定义的“标准接口”，但并非所有 Hypervisor 都实现——例如某些定制内核或老版 QEMU 可能不响应 - 部分安全敏感环境（如 Intel TDX、AMD SEV-SNP guest）会拦截或伪造该 leaf，返回空或随机值
- 不能依赖
EAX的子叶数做兼容性判断：KVM 返回 0x40000001，但 VMware 可能只支持 0x40000000
为什么单纯靠 CPUID 无法 100% 确定虚拟化状态
因为 Hypervisor 可以选择性地虚拟化、隐藏甚至篡改 CPUID 响应。尤其在嵌套虚拟化或安全容器场景中，CPUID 不再是可信信源。
典型绕过方式：
- 禁用
HYPERVISOR_PRESENT位（如某些反作弊驱动或隐私沙箱要求） - 将
0x40000000leaf 返回全零，伪装成物理机 - 对客户机暴露不完整的 feature bits（例如隐藏
VMXON支持，即使底层支持）
真正鲁棒的做法是组合检测：比如检查 /proc/cpuinfo 中的 hypervisor flag（Linux）、dmidecode -s system-product-name、TSC 不稳定性、特定 I/O 端口响应延迟等。但这些已超出 CPUID 范畴。
CPUID 提供的是最快速、最轻量的初步线索，不是最终判决书。实际工程中，若发现 CPUID 显示“无 Hypervisor”但其他指标异常，反而更值得警惕。
