虚拟机需要硬件虚拟化扩展支持，因VT-x与AMD-V通过引入新CPU模式、加速VM切换、实现EPT/NPT内存虚拟化及I/O直通，大幅降低Hypervisor开销，提升性能与稳定性；无此支持则依赖软件模拟，导致效率低下、兼容性差、资源消耗高，64位系统及现代功能难以运行。
虚拟机需要虚拟化扩展指令支持，主要是因为这些硬件层面的支持能够极大地提升虚拟机的运行效率、稳定性和安全性，让虚拟机能以接近原生系统的性能运行，同时有效隔离各个虚拟环境。说白了，没有它们，虚拟化在性能上就是个大坑。
虚拟机，这个概念大家都不陌生，它就像一台在你的物理电脑里跑的“电脑中的电脑”。但它要运行起来，可不是简单地把一个操作系统扔进去就行。操作系统天生就觉得它自己是老大，拥有CPU、内存等所有硬件资源。但虚拟化环境里，这些资源都是共享的，而且是虚拟的。
早期，在没有硬件虚拟化扩展的日子里，虚拟机软件（也就是Hypervisor，比如VMware Workstation或VirtualBox在没有KVM或Hyper-V支持时）为了让客户操作系统（Guest OS）能跑起来，得做很多“翻译”工作。客户操作系统想执行一个特权指令（比如直接访问硬件），CPU发现它没有权限，就会触发一个“陷阱”（trap），把控制权交给Hypervisor。Hypervisor拿到控制权后，就得模拟这个指令的行为，然后把结果返回给客户操作系统。这个过程，术语叫“二进制翻译”或者“陷阱和模拟”（trap-and-emulate）。
想想看，每一次客户操作系统想做点“大事”，都得经过这么一套复杂的“翻译-模拟-返回”流程，性能损耗是巨大的。这就像你每次要给外国朋友点餐，都得先跟翻译说，翻译再跟服务员说，服务员再跟翻译说，翻译再跟你说。效率能高吗？
硬件虚拟化扩展如何提升虚拟机性能？
其实，Intel的VT-x和AMD的AMD-V就是为了解决这个痛点而生的。它们在CPU层面引入了一套新的指令集和操作模式，让CPU自己就能直接处理很多虚拟化相关的任务。这在我看来，是虚拟化技术发展的一个里程碑。
具体来说，这些扩展做了几件事：
- 减少特权指令的陷阱次数： 硬件虚拟化扩展引入了新的CPU运行模式（比如Intel的VMX root operation和VMX non-root operation）。客户操作系统在non-root模式下运行时，即使执行特权指令，CPU也能直接在硬件层面判断并处理，而不再是简单地触发陷阱给Hypervisor。这大大减少了Hypervisor介入的频率，降低了上下文切换的开销。
- 高效的VM-entry和VM-exit： 当CPU需要从Hypervisor切换到客户操作系统，或者从客户操作系统切换回Hypervisor时（VM-entry/VM-exit），硬件会提供专门的指令和机制来加速这个过程。这比纯软件模拟的上下文切换快得多。
- 内存虚拟化支持（EPT/NPT）： 这可能是最重要的性能提升点之一。客户操作系统有自己的“物理地址空间”概念，但这些地址在物理机上其实是虚拟的。在没有硬件支持时，Hypervisor需要维护一套“影子页表”（shadow page table）来实时翻译客户操作系统的物理地址到宿主机的物理地址，这个过程非常耗费CPU和内存资源，而且容易导致TLB（Translation Lookaside Buffer）缓存失效，性能急剧下降。有了Intel的EPT（Extended Page Tables）或AMD的NPT（Nested Page Tables），CPU可以直接在硬件层面完成两级地址转换（客户OS虚拟地址 -> 客户OS物理地址 -> 宿主机物理地址），Hypervisor几乎不用干预。这样一来，内存访问速度大幅提升，虚拟机的整体性能也随之飙升。
- I/O虚拟化辅助： 虽然不全是CPU扩展的功劳，但像Intel VT-d和AMD-Vi这样的I/O虚拟化技术，允许虚拟机直接访问物理硬件设备（PCI passthrough），绕过Hypervisor的模拟层，进一步提升了I/O性能，尤其对图形密集型应用或高性能存储至关重要。
没有虚拟化扩展，运行虚拟机有哪些局限性？
在我个人看来，没有虚拟化扩展支持的虚拟机体验，用“差强人意”来形容都算客气了。
- 性能瓶颈： 这是最直接的影响。纯软件模拟的开销太大，导致客户操作系统运行缓慢，响应迟钝，尤其是在进行CPU密集型任务或内存密集型操作时，性能会变得非常糟糕。你可能会觉得虚拟机卡顿得像回到了上世纪。
- 兼容性问题： 很多现代的64位操作系统，尤其是服务器操作系统，它们在设计时就默认有硬件虚拟化扩展的存在。如果没有这些扩展，它们可能根本无法安装或正常运行，或者只能运行在非常有限的模式下。比如，Windows 8/10/11的Hyper-V、WSL2等功能都强制要求CPU支持VT-x/AMD-V。
- 资源消耗高： 由于Hypervisor需要做大量的软件模拟和翻译工作，它自身会消耗更多的CPU周期和内存资源，留给客户操作系统的资源自然就少了。这会限制你能同时运行的虚拟机数量，或者单个虚拟机的可用资源。
- 稳定性挑战： 复杂的软件模拟层更容易出现bug和兼容性问题，导致虚拟机运行不稳定，甚至崩溃。
Intel VT-x与AMD-V在技术实现上有何异同？
虽然Intel的VT-x和AMD的AMD-V在名称和一些底层实现细节上有所不同，但它们的核心目标和原理是高度一致的：通过硬件辅助来提升虚拟化效率。
-
共同点：
- 目标一致： 都是为了减少Hypervisor的软件开销，让客户操作系统更接近原生运行。
- 引入新CPU模式： 都引入了专门的CPU操作模式，用于区分Hypervisor和客户操作系统，并管理它们之间的切换。
- 内存虚拟化辅助： 都提供了硬件层面的二级地址转换机制（Intel的EPT和AMD的NPT/RVI），极大地简化了内存管理。
- I/O虚拟化扩展： 两家都有对应的I/O虚拟化技术（Intel的VT-d和AMD的AMD-Vi），用于直接设备分配。
-
不同点（更多是实现细节）：
- 命名： Intel使用VT-x、VMX（Virtual Machine Extensions）、EPT；AMD使用AMD-V、SVM（Secure Virtual Machine）、NPT（Nested Page Tables）或RVI（Rapid Virtualization Indexing）。这些只是不同公司的叫法。
- 控制结构： Intel使用VMCS（Virtual Machine Control Structure）来存储和控制虚拟机的状态，而AMD使用VMCB（Virtual Machine Control Block）。它们的功能类似，都是CPU用于管理虚拟机执行上下文的数据结构，但具体字段和操作方式不同。
- 指令集细节： 虽然都是硬件辅助虚拟化，但底层的VM-entry/VM-exit指令以及其他虚拟化管理指令在操作码和参数上会有所差异。这些差异对于普通的虚拟机用户来说是透明的，但对于Hypervisor的开发者而言，需要针对不同的CPU架构编写不同的代码。
总的来说，无论是VT-x还是AMD-V，它们都代表了现代CPU为了适应虚拟化趋势而进行的根本性变革。没有它们，虚拟化技术可能永远无法达到我们今天所看到的普及程度和高性能表现。
