如果你最近折腾过 WSL2大概率被这么一条报错劝退过此计算机上未启用虚拟化。请确保计算机固件设置中“虚拟机平台”已启用。我第一次看到这个提示时第一反应是骂 Windows 又抽风后来才知道问题根本不在系统而在我那台工控机的 BIOS 里——CPU 的硬件虚拟化开关根本没有打开。这件事也成了我写计算虚拟化系列的第一课所有上层虚拟化工具KVM、Hyper-V、VirtualBox、VMware底层都躲不开 CPU 虚拟化这个地基。计算虚拟化的第一站绕不开 CPU 虚拟化因为虚拟机的所有指令最终都要交给物理 CPU 去执行CPU 这一层不打开局面内存虚拟化和 I/O 虚拟化都无从谈起。1. 那次WSL2 无法启动的报错就是 CPU 虚拟化的入门课1.1 报错长什么样我当初是怎么排查的那是在一台老款 ThinkPad 上装 WSL2系统是 Windows 10 21H2。我执行完wsl --install重启然后运行wsl终端里弹出来一大段英文核心是Please enable the Virtual Machine Platform in Windows features and ensure virtualization is enabled in the BIOS后面还跟着一个错误码0x80370102。我当时的排查路径很典型先怀疑 Windows 功能没开启跑了一圈启用或关闭 Windows 功能把适用于 Linux 的 Windows 子系统和虚拟机平台都勾上了重启还是报错。再去 Microsoft Learn 查0x80370102官方文档翻来覆去就那几句话要么是虚拟机平台没开要么是 BIOS 没开虚拟化。最后我进了 BIOS在 Advanced 菜单里翻到Intel Virtualization Technology发现它被设置成了 Disabled。改成 Enabled保存重启WSL2 才正常起来。这个排查过程本身不复杂但它恰好把 CPU 虚拟化的两个关键位置指出来了一个是操作系统层面的虚拟机平台功能另一个是固件层面的硬件虚拟化开关。Windows 功能里那个虚拟机平台是不是虚拟机管理器而是 Hyper-V 依赖的基础组件而 BIOS 里那个 VT-x 开关控制的才是 CPU 是否对外暴露完整的虚拟化指令集。1.2 从这次报错引出 CPU 虚拟化的真正含义很多人以为 CPU 虚拟化就是在电脑里开虚拟机这个理解方向没问题但不够准确。CPU 虚拟化真正做的事情是把一颗物理 CPU 抽象成多个逻辑处理器也就是 vCPU让每个虚拟机都觉得自己独占了一颗或多颗 CPU并且每个虚拟机里运行的操作系统都能像在物理机上一样执行指令、管理中断、切换进程。从 WSL2 的角度看它之所以需要 CPU 虚拟化是因为 WSL2 已经不再是 WSL1 那种系统调用翻译层了。WSL1 通过一个翻译进程把 Linux 的系统调用转成 Windows 内核调用不需要虚拟化WSL2 则是一个完整的 Linux 内核跑在轻量级虚拟机里。既然要跑完整内核就需要 Hyper-V 承担虚拟机监视器VMM的职责而 Hyper-V 又要求 CPU 必须支持并开启硬件虚拟化。这条链路上任何一个环节掉了链子WSL2 都启动不了。我后来在给团队做虚拟化培训时经常说一句话CPU 虚拟化是计算虚拟化的地基内存虚拟化、I/O 虚拟化、网络虚拟化都是在它之上盖楼。地基不牢后面全白搭。所以这篇文章咱们就从 CPU 这一层开始把虚拟化最核心的原理讲透。2. 为什么 CPU 虚拟化这么难特权级、敏感指令与老牌曲线救国方案2.1 内核态与用户态操作系统对 CPU 的门禁管理要理解 CPU 虚拟化的难度先得理解物理 CPU 本身是怎么管控指令执行的。x86 架构里CPU 分了多个特权级通常是 Ring 0 到 Ring 3操作系统内核运行在 Ring 0普通应用程序运行在 Ring 3。Ring 0 可以执行特权指令比如修改 CR3 寄存器、操作中断描述符表 IDT、读写控制寄存器Ring 3 碰到这些指令会直接触发异常。这个设计初衷是为了安全——用户程序不能随便关中断、改页表、操作硬件。但放到虚拟化场景里麻烦就来了。虚拟机里的客户机操作系统以为自己是物理机上的内核它理所当然地想运行在 Ring 0想执行那些特权指令。可是如果真让它随便执行它就能直接控制物理 CPU、物理内存、物理中断控制器那宿主机上其他虚拟机就全乱了。所以虚拟化的第一个核心矛盾是客户机操作系统想要最高特权但 VMM 必须拿走最高特权。VMM 自己得运行在物理 CPU 的最高特权级上客户机内核则被降级到低特权级客户机想要执行特权指令时必须被 VMM 截获由 VMM 模拟执行或转发给物理硬件。2.2 Popek-Goldberg 条件与 x86 的尴尬虚拟化领域有一个经典理论框架叫 Popek-Goldberg 虚拟化条件。它提了两个核心要求敏感指令集合必须是特权指令集合的子集。也就是说所有会改变系统资源状态的敏感指令都应该在非特权级执行时触发陷入从而让 VMM 有机会介入。麻烦的是x86 架构早期设计时压根没想过虚拟化这回事。x86 上存在一些敏感指令但它们并不是特权指令。比如SGDT、SIDT、SLDT、STR、SMSW这些读取系统描述符和机器状态字状态的指令在 Ring 3 也能执行不会触发陷入。客户机操作系统一执行这些指令读到的就是 VMM 的描述符表信息而不是它自己虚拟出来的那套。这就是所谓的非特权敏感指令问题它让纯软件陷入再模拟的虚拟化路线在 x86 上走不通。这个问题的分量在于它决定了早期 x86 虚拟化必须走非常规路线。VMM 可以静态扫描客户机指令流把非特权敏感指令替换成陷入指令或 VMM 调用也叫二进制翻译。这种方案工作量大、动态行为复杂、性能损耗高但确实是硬件虚拟化成熟前VMware 等产品能够落地的关键。2.3 二进制翻译和半虚拟化硬件帮手出现之前的活法在 Intel VT-x 和 AMD-V 普及之前x86 平台上的虚拟化主要靠两条路二进制翻译和半虚拟化。二进制翻译的思路是 VMM 在客户机执行前把整个指令块扫描一遍把敏感的、非特权的、或需要重定位的指令翻译成等价的安全指令序列然后缓存起来执行。热门代码路径翻译一次后反复使用性能可以接受冷门路径或者动态生成的代码就可能频繁触发翻译性能暴跌。VMware Workstation 早期就是靠这个技术从 x86 虚拟化的死胡同里钻出来的它把客户机指令和宿主机指令之间的鸿沟用软件办法填上。半虚拟化走的是另一条路与其偷偷摸摸翻译指令不如直接修改客户机操作系统把敏感操作主动换成对 VMM 的系统调用也就是 hypercall。客户机内核明确知道自己在虚拟环境里跑需要操作页表或者中断时就主动举手找 VMM。Xen 早期就是靠这个方案做出高性能的代价是客户机系统必须打补丁Windows 这种闭源系统就不太配合。这两条路到今天都没有完全消失。二进制翻译依然在跨架构虚拟化里有应用场景半虚拟化思想也演化成了 VirtIO 驱动体系。但它们的共同问题是把大量工作交给软件而软件做指令级模拟永远比硬件直接支持慢一个数量级。这也是为什么硬件虚拟化一出现立刻成为计算虚拟化的主流。3. Intel VT-x 与 AMD-V硬件为虚拟化开了多少后门3.1 VMX 根模式与非根模式VMM 和客户机终于各就各位Intel VT-x 和 AMD-V 的推出改变了整个虚拟化产业。它们的思路非常一致既然软件模拟耗时那就在 CPU 内部新增一套硬件运行模式专门给虚拟化使用。Intel 把这套东西叫做 VMX全称 Virtual Machine Extensions。VMX 引入了两种 CPU 工作模式VMX root operation 和 VMX non-root operation。VMM 运行在 root 模式客户机运行在 non-root 模式。注意这两个模式不是新的特权级它们是对原有 Ring 0~3 的再封装。也就是说客户机的内核在 non-root 模式下依然认为自己运行在 Ring 0但一旦它执行了敏感指令或者触发某些事件CPU 会自动保存现场、切换到 root 模式把控制权交还给 VMM。AMD 那边叫 SVM全称 Secure Virtual Machine对应的两种模式叫 host mode 和 guest mode本质思路一致只是数据结构和控制方式有差异。这套硬件机制解决了最根本的问题敏感指令不再依赖软件翻译硬件直接负责截获和切换VMM 要做的只是在入口和出口处处理业务逻辑。3.2 VM Entry 与 VM Exit每一次切换都是性能选择题有了 VMX 模式后CPU 虚拟化的核心流程就变成了两个方向上的切换VM Entry 是 CPU 从 VMM 进入客户机模式开始执行客户机指令VM Exit 是客户机因为某种原因退出CPU 回到 VMM。这两个术语你会在所有涉及虚拟化的资料里反复看到它们就是 vCPU 运行的脉搏。每次 VM Exit 都要保存客户机的 CPU 状态、加载 VMM 的 CPU 状态、读取退出原因、找到对应的处理函数处理完再 VM Entry 回去。频繁的 VM Exit 直接拉低虚拟机性能。典型的高频退出原因包括访问特权寄存器、执行 CPUID 指令、中断和异常、访问 I/O 端口、页表操作等。每个原因都对应一个退出原因码VMM 可以据此决定是直接模拟、还是调度其他 vCPU、还是转发给硬件处理。我在实际调优 KVM 虚拟机时最常用的工具就是perf kvm和/sys/kernel/debug/kvm/下的统计信息专门看kvm_exit的类型分布。如果发现cpuid退出特别多说明客户机频繁执行 CPUID 指令可以考虑通过 PV 特性或优化应用减少 CPUID 调用。如果ept_violation多说明内存访问模式有问题需要调整透明大页或内存 balloon。说到底CPU 虚拟化的性能调优就是在和 VM Exit 做斗争。3.3 VMCS/VMCB硬件与 VMM 之间的交接备忘录VT-x 和 SVM 之所以能实现快速切换靠的是一块内存数据结构来记录 CPU 的上下文和虚拟化控制信息。Intel 叫 VMCS全称 Virtual Machine Control StructureAMD 叫 VMCB全称 Virtual Machine Control Block。VMCS 里存的东西大致分几类客户机状态区包括客户机的寄存器、段寄存器、控制寄存器、指令指针等宿主机状态区保存 VMM 的上下文VM 执行控制字段控制客户机里哪些指令需要退出、哪些事件需要拦截VM 退出信息字段记录这次 VM Exit 的原因和详细信息VM 进入控制字段控制进入客户机时的 CPU 状态加载行为。理解 VMCS 的意义在于你对虚拟化的很多疑问都能在它身上找到答案。为什么虚拟机迁移时要保存 CPU 状态因为 VMCS 里存着客户机 CPU 的完整快照。为什么某些 CPU 特性不能直通给虚拟机因为 VMCS 执行控制字段里没有对应的透传配置或者硬件层面不允许。我早期看 KVM 源码第一件事就是去arch/x86/kvm/vmx/vmx.c里翻 VMCS 字段的读写逻辑看完才真正理解硬件虚拟化到底帮你做了哪些事。4. 内存虚拟化为什么算在 CPU 虚拟化的账上从影子页表到 EPT4.1 一个 vCPU 背后其实有第二张地址映射表聊 CPU 虚拟化不可能绕开内存虚拟化因为 CPU 执行的每一条指令几乎都要访存vCPU 一旦需要访问内存就涉及到客户机地址怎么映射到物理内存地址的问题。在虚拟机里客户机操作系统管理的是客户机虚拟地址 GVA 和客户机物理地址 GPA。客户机物理地址对 VMM 来说并不是真正的物理地址它只是 VMM 抽象出来的一段内存空间。VMM 需要把 GPA 再映射成宿主机物理地址 HPA。所以一次普通的内存访问在虚拟化场景下要经历两层地址转换GVA → GPA → HPA。这个链条上的任何断层都会直接表现为 vCPU 的性能卡顿或者虚拟机崩溃。4.2 影子页表软件维护的无奈与代价在没有 EPT 的年代VMM 是怎么处理两层地址映射的答案是影子页表。VMM 为每个客户机进程维护一份影子页表这份页表直接把 GVA 映射到 HPA。客户机操作系统更新自己的页表时VMM 必须拦截这个更新解析客户机页表结构同步修改影子页表然后把物理 CPU 的 CR3 指向影子页表。问题的根源在于客户机内核会非常频繁地更新页表。每次进程切换、每次内存分配、每次 mmap都可能触发页表更新每一次更新都可能造成 VM ExitVMM 要做的工作量非常大。为了优化一些实现会给影子页表做写保护客户机一写页表就陷入VMM 再懒更新。但不管怎么优化软件维护页表的开销和复杂度都是硬伤而且还会引入 TLB 频繁刷新的问题。4.3 EPT 两阶段翻译和 TLB 的 VPID 优化Intel 的 EPT全称 Extended Page Tables是硬件辅助内存虚拟化的关键。它把 GVA → GPA → HPA 的两阶段翻译全部交给硬件来完成。客户机操作系统管理第一层 GVA → GPA硬件通过 EPT 页表完成第二层 GPA → HPA。客户机更新自己的页表不再需要 VMM 介入EPT violation 才会触发 VM Exit。硬件的加入不仅避免了大量的 VM Exit还带来了另一个好处TLB 可以缓存两阶段转换结果。更妙的是 VT-x 提供了 VPID也就是 Virtual Processor Identifier每个 vCPU 有一个独立的标识TLB 条目打上 VPID 标签这样 VM Entry/VM Exit 时不再需要整体刷新 TLB切换成本大幅下降。AMD 里对应的机制叫 ASID作用一样。这套硬件方案对性能的提升是数量级的。我做过一个很直观的测试在同样一台物理机上关闭 EPT 用纯软件模式跑内存密集型负载和开启 EPT 跑前者吞吐量能跌到后者的六成左右某些极端场景更低。这就是为什么内存虚拟化虽然名字上属于内存但在技术实现上始终和 CPU 虚拟化绑在一起讲。5. 现代虚拟化产品里 CPU 虚拟化是怎么落地的KVM、VirtualBox 和 WSL25.1 KVM把硬件虚拟化能力直接暴露给 Linux 内核KVM 的全称是 Kernel-based Virtual Machine它做的事情很纯粹把 VT-x / AMD-V 暴露的硬件虚拟化能力封装成 Linux 内核模块然后通过/dev/kvm字符设备提供给用户空间。QEMU 在用户空间配合 KVM负责设备模拟和 vCPU 的创建、运行、退出处理。KVM 里每创建一个 vCPU本质上是创建了一个文件描述符用户空间通过KVM_RUNioctl 让 CPU 进入 VMX non-root 模式。vCPU 发生 VM Exit 后内核态 KVM 模块会做第一轮处理处理不了的再返回到 QEMU 用户态。这个架构把 CPU 虚拟化最关键的部分放进了内核性能和实时性都很好所以 Linux 平台上 KVM 几乎是唯一事实标准。跑 KVM 虚拟机时我建议你用virsh vcpuinfo看 vCPU 的拓扑和亲和性再用numastat -p观察 VM 进程的 NUMA 访问情况。CPU 虚拟化不是说开了硬件加速就完事了vCPU 的物理核绑定、NUMA 亲和性、CPU 份额限制都会直接影响最终性能。5.2 VirtualBox、VMware 与 Hyper-V 的路线差异VirtualBox 和 VMware Workstation 是桌面场景最常见的两款虚拟化软件它们的 CPU 虚拟化策略有明显差异。VirtualBox 默认使用自己的内核驱动在硬件虚拟化可用时走 VT-x/SVM不可用时会回退到软件虚拟化模式但性能会差很多早期的 VBox 软件模拟 x86 的体验可以用灾难来形容。VMware Workstation 的路线更老练早期靠二进制翻译起家后来硬件虚拟化成熟后切到了 VT-x/SVM但它保留了很强的兼容逻辑。在嵌入式场景、老 CPU、嵌套虚拟化等环境里VMware 的动态二进制翻译依然作为备选方案存在。这种硬件不行软件凑的设计让它在各种稀奇古怪的环境里都能跑起来。有一点值得提醒Windows 上如果要同时用 Hyper-V 和 VirtualBox/VMware会踩到虚拟化独占的问题。Hyper-V 启动后会占据 CPU 的虚拟化特性VirtualBox 6 及更早版本直接无法启动 64 位虚拟机VMware 则从 Workstation 15.5 开始通过 Windows Hypervisor Platform 与 Hyper-V 共存。解决思路不是二选一而是保持共存时统一走 Windows Hypervisor Platform 这层兼容接口。5.3 WSL2 背后那套轻量虚拟机的 CPU 调度思路回到开头那个 WSL2它在 CPU 虚拟化上其实有一个很值得琢磨的设计。WSL2 跑在 Hyper-V 创建的轻量级虚拟机里但它并不像传统虚拟机那样给 vCPU 分配固定核数和固定内存。微软专门做了一套动态内存回收机制让 WSL2 的内存可以在宿主和 VM 之间弹性调节。CPU 调度上WSL2 的 vCPU 数量和物理核数默认是挂钩的现代 Windows 版本里你可以在.wslconfig里通过processors4来限制 vCPU 数量。限制 vCPU 在资源密集场景下不是坏事反而能减少 VM Exit 引起的调度抖动让宿主系统保持流畅。内存上限用memory4GB控制这两个参数是 WSL2 性能调优最先应该动的旋钮。如果你在 WSL2 里跑编译任务感受最明显的是多核高并发时 CPU 占用能够打满但宿主机的鼠标和窗口响应可能会变卡。这是因为 Hyper-V 的 vCPU 调度和宿主机线程调度共同竞争物理核没有给 WSL2 设置 CPU 亲和性的情况下vCPU 会漂移到不同物理核上缓存局部性变差宿主系统也容易被抢占。我自己的处理方式是把 WSL2 的.wslconfig设置成processors物理核数-2给宿主机留一点余量。6. 虚拟化打不开的实操排查从 BIOS 到 Windows 功能的完整链路6.1 先用系统自带工具确认硬件虚拟化状态面对此计算机上未启用虚拟化这类问题先别急着进 BIOS可以先用工具确认硬件层面到底处于什么状态。Windows 下最简单的办法是打开任务管理器切到性能标签点 CPU看右下角虚拟化这一项是已启用还是已禁用。如果是已启用说明固件层面的开关已经打开问题大概率在系统功能如果是已禁用就算 Windows 功能全开了也无济于事。更详细的方式是在命令提示符里执行systeminfo输出末尾有一块 Hyper-V 要求会列出四个项目虚拟机监视器模式扩展、固件中已启用虚拟化、二级地址转换、数据执行保护。如果固件中已启用虚拟化显示为否那就是 BIOS 里没开。如果其他项有问题则需要去查 CPU 型号是否支持 SLAT也就是 EPT/NPT。6.2 BIOS/固件里该找哪些开关不同品牌的主板BIOS 里虚拟化开关的位置和叫法差异很大。Intel 平台常见的叫法是Intel Virtualization Technology缩写 VT-x有些主板叫Virtualization Technology或VT-d分开列。AMD 平台常见的叫法是SVM Mode全称 Secure Virtual Machine有些主板也叫AMD Virtualization。注意VT-d是 I/O 虚拟化相关的 Intel VT-d和 CPU 虚拟化的 VT-x 不是一回事两个开关最好都打开但对 CPU 虚拟化起决定作用的是 VT-x。我遇到过最坑的一种情况是 BIOS 里明明显示 VT-x 已开启但 Windows 任务管理器依然显示虚拟化已禁用。后来发现是因为开机时 Windows 的 VBS也就是基于虚拟化的安全没成功初始化或者被安全软件干扰。解决方案是先关闭系统里的内核隔离-内存完整性再重启或者直接在 BIOS 里检查Trusted Execution Technology和VT-d相关的联动选项。6.3 Hyper-V、内核隔离与第三方虚拟化软件的共存问题Windows 上虚拟化软件的冲突很多时候比硬件开关更令人头疼。Windows 10/11 默认开启内核隔离-内存完整性后会调用 Hyper-V 的虚拟化能力来保护内核Hyper-V 平台一旦被激活第三方虚拟化软件和 Hyper-V 之间就可能出现虚拟化特性争抢。具体表现VirtualBox 打开虚拟机时报VT-x is not available或提示需要关闭 Hyper-V即使任务管理器显示虚拟化已启用。这是因为 VirtualBox 默认直接使用 VT-x而 Hyper-V 已经用掉了这个能力。解决的办法不是删掉 Hyper-V而是在启用或关闭 Windows 功能里勾上虚拟机平台和Windows 虚拟机监控程序平台让 VirtualBox/VMware 通过 WHP 接口来使用硬件虚拟化。注意 VBox 6.0 以上才支持 WHP太老版本基本无解。VMware Workstation 从 15.5 开始也支持与 Hyper-V 共存但前提同样是开启Windows 虚拟机监控程序平台。我有个同事曾因为做 Docker Desktop 和 VMware 共存折腾了一下午最后发现是 Windows 预览版里 VBS 强制开启导致虚拟机嵌套异常关掉内核隔离就好了。6.4 嵌套虚拟化虚拟环境里再开一个虚拟环境的坑还有一种很常见的虚拟化打不开场景发生在虚拟环境内部。比如你在 VMware 虚拟机里装了一个 Linux然后在里面又部署 KVM 去跑虚拟机或者想直接在 Windows 虚拟机里开 WSL2。这时候报错信息往往还是虚拟化未启用原因很简单VMware/VirtualBox 默认不会把 VT-x 指令透传给客户机除非你在虚拟机设置里勾选虚拟化 Intel VT-x/EPT 或 AMD-V/RVI。嵌套虚拟化的性能损失通常很明显。每多一层虚拟化就意味着多一层 VM Exit 的处理嵌套模式下 CPU 虚拟化指令需要被外层 VMM 模拟延迟会放大不少。如果只是学习实验嵌套虚拟化完全可以接受如果用来跑生产负载建议尽量不要嵌套。厂商也都在完善嵌套支持KVM 对嵌套虚拟化的支持相对成熟很多云厂商的裸金属服务器也提供嵌套虚拟化能力但那是另一个复杂话题了。回到 CPU 虚拟化本身我想说的是它不像那些花哨的分布式系统或者 AI 框架它是一种地基型技术。你可能天天在用它却几乎感觉不到它的存在。WSL2 启动是它KVM 跑云主机是它Android 模拟器流畅运行也是它。搞懂 VT-x、VM Exit、EPT 这些概念你再看虚拟化相关的日志、性能指标思路会完全不一样。如果这篇文章能帮你把 WSL2 那次报错背后的原理理清楚那它就不只是解决了一个问题而是帮你把计算虚拟化的第一块地基打扎实了。
