虚拟化与地址转换

凌晨3点17分，某云服务商的on-call工程师被紧急告警叫醒：一台256核、2TB内存的物理服务器上，运行着64个虚拟机的数据库实例突然集体出现延迟飙升——P99延迟从正常的2ms暴涨到50ms以上。CPU利用率并不高，内存也没有耗尽，但perf计数器揭示了一个触目惊心的数字：TLB Miss率从正常的0.3%飙升到12%，每次TLB Miss触发的嵌套页表遍历平均消耗800 $\sim$ 1200个时钟周期。根因很快被定位——一个运维脚本在凌晨3点触发了所有VM的在线快照，Hypervisor为追踪脏页将大量Stage-2 EPT映射从2MB大页降级为4KB小页（page shattering），导致TLB的有效覆盖范围骤降了500倍，64个VM的工作集同时争夺有限的TLB容量，形成了灾难性的TLB thrashing。这个事故生动地说明了一个事实：在虚拟化环境下，地址转换不再是一个"透明"的硬件细节，而是直接关系到整个数据中心服务质量的关键路径。

统一视角连接。 本书的核心论点是：处理器设计的本质是在有限的晶体管预算和功耗约束下，通过投机和并行的层层叠加来逼近指令吞吐率的理论上限。虚拟化将这一优化问题推向了一个新的维度——它是对物理资源的并行共享，使一台物理机上的多个操作系统能够"投机性地"认为自己独占硬件。这种并行共享的代价集中体现在地址转换上：第 10.0 章中讨论的单层页表遍历在虚拟化下变成了嵌套的二维遍历，每一层Guest页表访问都需要一次完整的Stage-2翻译——代价从加法变成了乘法。第 11.0 章中精心设计的TLB层次结构，在虚拟化环境下面临容量稀释和标签空间膨胀的双重挑战。理解这些代价的根源和缓解策略，是设计面向云计算时代的高性能处理器的必修课。

在第 10.0 章和第 11.0 章中，我们讨论了单一操作系统环境下的虚拟存储器机制：操作系统维护页表，处理器的MMU将虚拟地址（VA）翻译为物理地址（PA），TLB缓存翻译结果以降低地址转换的开销。这一机制在过去数十年中运行得非常好。然而，随着云计算和数据中心的兴起，在一台物理服务器上同时运行数十乃至上百个虚拟机（Virtual Machine, VM）已成为常态。虚拟化技术要求每个VM中的Guest操作系统都认为自己独占整个物理地址空间，而实际的物理内存由Hypervisor统一管理和分配。这引入了一个全新的地址翻译层次：Guest虚拟地址（GVA）首先由Guest OS的页表翻译为Guest物理地址（GPA），然后GPA再由Hypervisor维护的嵌套页表翻译为真正的Host物理地址（HPA）。这种二阶段地址转换（Two-Stage Address Translation）是虚拟化环境下处理器地址翻译机制的核心挑战。

读完本章，你将理解为什么嵌套遍历是乘法而非加法，Combined TLB与Split TLB各自的适用场景，VM-Exit/Entry的地址转换代价如何量化，以及硬件如何通过多层TLB缓存将虚拟化的地址转换开销从理论上的 $6\times$ 降低到实际的5–10%。

本章系统地讨论虚拟化环境下的地址转换机制。首先介绍二阶段地址转换的基本概念和四大主流架构（Intel EPT、AMD NPT、ARM Stage-2、RISC-V H扩展）的具体实现。然后深入分析嵌套页表遍历带来的巨大性能开销——一次Guest页表遍历在最坏情况下需要多达24次物理内存访问——以及硬件和软件为缓解这一开销所采取的各种优化手段，包括Combined TLB与Split TLB的架构抉择、VM-Exit/Entry的地址转换代价，以及不同工作负载下虚拟化开销的量化分析。最后讨论IOMMU（I/O Memory Management Unit）技术，它将虚拟化地址转换的概念从处理器核心扩展到I/O设备，使得DMA操作也能在虚拟化环境下安全、高效地进行。

二阶段地址转换

虚拟化的需求

虚拟化（Virtualization）的核心思想是在一台物理机器上模拟出多台逻辑机器，每台逻辑机器（即虚拟机）都拥有独立的CPU、内存、I/O资源视图，可以运行自己的操作系统和应用程序。虚拟化的关键在于Hypervisor（也称为Virtual Machine Monitor, VMM），它负责管理物理资源并在多个VM之间进行分配和隔离。

根据Hypervisor的运行位置，虚拟化架构分为两类：

（1）Type-1 Hypervisor（裸金属型）。Hypervisor直接运行在物理硬件之上，不依赖任何Host操作系统。所有Guest OS都运行在Hypervisor之上。这是数据中心和云计算中最常见的部署方式。典型代表包括VMware ESXi、Microsoft Hyper-V、Xen和KVM（Linux内核本身充当Hypervisor）。Type-1 Hypervisor的优势在于性能开销小——没有Host OS的中间层，Hypervisor可以直接控制硬件资源的分配。

（2）Type-2 Hypervisor（宿主型）。Hypervisor作为一个应用程序运行在Host操作系统之上。Guest OS的I/O操作和特权指令需要经过Hypervisor和Host OS两层转发。典型代表包括VirtualBox、VMware Workstation和QEMU。Type-2 Hypervisor的优势在于易于安装和使用——用户只需在现有操作系统上安装一个应用程序即可。但由于多了一层Host OS的间接层，性能开销通常大于Type-1。

无论是哪种类型的Hypervisor，虚拟化面临的核心挑战之一就是内存虚拟化（Memory Virtualization）。在非虚拟化环境中，操作系统直接管理物理内存——它维护页表将进程的虚拟地址映射到物理地址，并通过CR3（x86）、TTBR（ARM）或satp（RISC-V）等寄存器告知MMU页表的基地址。在虚拟化环境中，Guest OS仍然维护自己的页表，但它所认为的"物理地址"实际上只是一个中间地址——Hypervisor需要再将这个中间地址翻译为真正的物理地址。

早期的虚拟化方案使用影子页表（Shadow Page Table）来解决这一问题。Hypervisor在内存中为每个Guest进程维护一份影子页表，将Guest的虚拟地址直接映射到Host物理地址，从而将两级翻译合并为一级。MMU实际使用的是影子页表而非Guest的原始页表。这一方案的性能开销很大：每当Guest OS修改其页表时（例如创建新进程、分配内存、处理缺页异常），Hypervisor必须拦截这些操作并同步更新影子页表。Guest OS对页表的修改是通过普通的Store指令完成的，因此Hypervisor需要将Guest页表所在的内存页标记为只读——任何对Guest页表的写入都会触发Page Fault，陷入Hypervisor进行同步处理。在某些工作负载下，影子页表的维护开销可以占到总执行时间的20% $\sim$ 40%。

影子页表同步的细节。当Guest OS通过普通Store指令修改页表（例如映射一个新页面），Hypervisor拦截这一写入的机制是写保护（write-protect）：Hypervisor将Guest页表所在的物理页标记为只读。Guest的Store指令试图写入只读页面时触发Page Fault（在VT-x术语中是EPT Violation或Guest Page Fault），处理器执行VM-Exit，控制权转移到Hypervisor。Hypervisor在Page Fault处理中：（1）读取Guest的Store指令以确定修改内容；（2）将修改应用到Guest页表的内存副本；（3）同步更新影子页表——将Guest的VA $\to$ GPA $\to$ HPA的合成映射写入影子页表；（4）恢复Guest执行。

这个过程中最昂贵的步骤不是影子页表的更新本身（通常只需要修改几个页表项），而是VM-Exit/Entry的固定开销（约1000–2000周期）和Guest指令模拟的开销（约100–500周期）。一个典型的进程创建操作（fork + exec）可能触发数百次Guest页表修改，导致数百次VM-Exit——累计开销可达数十万周期。

影子页表的另一个严重问题是内存开销。Hypervisor需要为Guest中的每个进程维护一份独立的影子页表。如果一个VM运行着100个进程，Hypervisor就需要维护100份影子页表。每份影子页表的大小与Guest页表相当（通常为数十KB到数MB），在多VM、多进程的场景下，影子页表的内存占用将非常可观。

为了消除影子页表的高开销，Intel、AMD、ARM和RISC-V先后在处理器硬件中引入了硬件辅助的二阶段地址转换，使MMU能够在硬件层面自动完成两级翻译，无需Hypervisor在软件层面维护影子页表。表表 12.1对比了影子页表与硬件辅助二阶段翻译的关键差异。

特性	影子页表	硬件二阶段翻译
TLB Miss处理	单次4级遍历（快）	嵌套遍历（慢，最多24次）
Guest页表修改	每次都需VM-Exit（慢）	无需Hypervisor介入（快）
内存开销	每进程一份影子页表	仅需一份嵌套页表
实现复杂度	Hypervisor软件复杂	硬件复杂，软件简单
适用场景	页表修改少的工作负载	通用工作负载

影子页表与硬件辅助二阶段翻译的对比

GVA到GPA到HPA的翻译

在二阶段地址转换中，一个Guest进程发出的内存访问地址需要经过两级翻译才能到达真正的物理内存：

第一阶段（Stage-1）：Guest VA $\to$ Guest PA。这一级翻译由Guest OS的页表完成，翻译规则与非虚拟化环境完全相同。Guest OS维护自己的CR3/TTBR/satp寄存器，指向Guest页表的基地址（注意：这个基地址本身也是GPA，不是HPA）。
第二阶段（Stage-2）：Guest PA $\to$ Host PA。这一级翻译由Hypervisor维护的嵌套页表（Nested Page Table / Extended Page Table / Stage-2 Page Table）完成。嵌套页表将Guest的物理地址空间映射到真正的Host物理地址空间。

图图 12.2展示了二阶段地址转换的完整流程。

关键的复杂性在于：Guest页表本身存储在Guest物理地址空间中。这一看似简单的事实是虚拟化地址转换所有复杂度的根源。当MMU遍历Guest页表时，它需要读取Guest页表项的内容，而这些页表项的地址是GPA。但MMU不能直接用GPA访问物理内存——GPA是一个中间地址，不对应任何物理DRAM位置。MMU必须先通过Stage-2翻译将GPA转换为HPA，才能真正从物理内存中读取Guest页表项的数据。每一次对Guest页表项的访问都需要这样一次完整的Stage-2翻译。这意味着，一次完整的二阶段地址转换并不是简单的"先做一次Stage-1遍历，再做一次Stage-2遍历"，而是Stage-1遍历的每一步都嵌套了一次完整的Stage-2遍历——这就是"嵌套"（Nested）的含义，也是二阶段翻译性能开销巨大的根本原因。我们将在12.2.1 节中详细分析这一开销。

Intel EPT

Intel在2008年发布的Nehalem微架构中引入了Extended Page Tables（EPT），这是x86架构实现硬件辅助二阶段地址转换的机制。EPT通过在VT-x（Virtual Technology for x86）框架中增加一组专用的页表结构，使处理器MMU能够自动完成GPA到HPA的翻译。

EPT的启用

EPT通过VMCS（Virtual Machine Control Structure）中的控制字段启用。Hypervisor在执行VMLAUNCH或VMRESUME进入Guest模式之前，将EPT的根页表物理地址（EPTP，EPT Pointer）写入VMCS的相应字段。EPTP包含以下信息：

EPT根页表的HPA（位[51:12]）：指向EPT PML4表的物理地址，4KB对齐。
EPT页表遍历的级数（位[5:3]）：通常设置为3，表示4级页表（EPT PML4 $\to$ EPT PDPT $\to$ EPT PD $\to$ EPT PT）。
内存类型（位[2:0]）：指定EPT页表结构本身的内存类型（如Write-Back或Uncacheable）。

EPT页表结构

EPT采用与x86-64常规页表类似的4级基数树结构，但页表项的格式有所不同。EPT使用48位GPA作为输入，各级页表项分别对应GPA的不同位段：

EPT PML4（Page Map Level 4）：使用GPA[47:39]（9位）索引，共512项。
EPT PDPT（Page Directory Pointer Table）：使用GPA[38:30]（9位）索引，共512项。可以映射1GB大页。
EPT PD（Page Directory）：使用GPA[29:21]（9位）索引，共512项。可以映射2MB大页。
EPT PT（Page Table）：使用GPA[20:12]（9位）索引，共512项。映射4KB页。

EPT页表项（EPTE）的格式与常规x86-64页表项有以下关键区别：

特性	常规页表项	EPT页表项
读权限	P（Present，位0）	R（Read，位0）
写权限	R/W（位1）	W（Write，位1）
执行权限	由NX位（位63）控制	X（Execute，位2）
用户/内核	U/S（位2）	无（EPT不区分特权级）
访问位	A（位5）	A（位8），可选
脏位	D（位6）	D（位9），可选
内存类型	通过PAT/MTRR	位[5:3]直接指定

EPT页表项与常规x86-64页表项的权限位对比

EPT页表项中，读、写、执行权限被拆分为三个独立的位，比常规页表的权限控制更灵活。特别是，EPT允许创建只执行（Execute-only）的页面映射——这在常规页表中是不可能的（常规页表中，可执行的页面必须也是可读的）。只执行页面在安全领域有重要应用，例如可以保护代码免受读取攻击（如ROP gadget的扫描）。

EPT页表项还包含一个内存类型字段（位[5:3]），允许Hypervisor直接在EPT中指定每个GPA范围的内存类型（Uncacheable、Write-Combining、Write-Through、Write-Protected或Write-Back），而无需依赖MTRR（Memory Type Range Registers）。这对虚拟化环境特别重要——Guest VM的MTRR设置只影响Guest的虚拟内存类型，实际的物理内存类型由EPT中的字段和Host的MTRR/PAT的组合决定。当EPT指定的类型与MTRR/PAT冲突时，处理器按照Intel定义的优先级规则进行合并（通常取更弱的缓存类型）。

EPT Violation与EPT Misconfiguration

当Guest的内存访问在EPT翻译过程中遇到权限违规（如试图写入一个只读的EPT映射）时，处理器触发EPT Violation，导致VM-Exit。Hypervisor捕获这一事件后可以进行相应处理（如实现写时复制、内存热迁移等）。

当EPT页表项中包含无效的字段组合（如设置了保留位，或内存类型字段中包含了未定义的值）时，处理器触发EPT Misconfiguration。这通常指示Hypervisor的页表管理存在bug。

EPT Accessed和Dirty位

Intel从Haswell微架构开始支持EPT的Accessed（A）和Dirty（D）位。当启用后，处理器在访问EPT映射的页面时自动设置A位（表示该页面被访问过），在写入时设置D位（表示该页面被修改过）。这两个位对Hypervisor的内存管理至关重要：

A位用于实现LRU近似算法——Hypervisor可以定期清除所有EPT页面的A位，然后检查哪些页面在下一个时间窗口内被重新设置了A位，从而识别活跃页面和冷页面。冷页面可以被优先选择进行内存气球回收（ballooning）或内存压缩。
D位用于实现脏页跟踪——在VM实时迁移（Live Migration）过程中，Hypervisor需要知道哪些页面自上次同步以来被修改过，以便只传输脏页到目标主机。没有硬件D位支持时，Hypervisor需要将所有EPT页面标记为只读，每次Guest写入都会触发EPT Violation，开销极大。

EPT的性能影响与优化

EPT的引入消除了影子页表的高昂软件开销，但引入了嵌套遍历的硬件开销。理解EPT的净性能影响需要对比分析：

设计权衡 1 — 影子页表与EPT的性能权衡

影子页表和EPT各自的性能特征在不同工作负载类型下有显著差异：

影子页表的优势场景——当Guest页表修改极其稀少时。影子页表使TLB miss的处理与裸机完全相同（单层4级遍历），代价仅在Guest修改页表时才出现（VM-Exit + 影子页表同步）。在极端情况下，如果Guest从不修改页表（例如一个没有内存管理的嵌入式Guest），影子页表的性能可以接近裸机。

EPT的优势场景——当Guest页表修改频繁时（这是绝大多数实际工作负载的情况）。每次进程创建、内存分配、缺页处理、mmap/munmap都会修改Guest页表。影子页表方案下，每次修改都触发VM-Exit（约1000周期）+ 影子页表同步（约200–500周期）；EPT方案下，Guest自由修改页表无需VM-Exit，代价仅在TLB miss时嵌套遍历（但被TLB和PWC大量缓存吸收）。

Intel的测量数据表明：在SPECjbb2005等Java工作负载中，影子页表的VM-Exit频率高达每秒数万次，而EPT将其降低到不足百次。在PostgreSQL等数据库工作负载中，EPT相比影子页表带来了15–30%的整体性能提升。

5级EPT

从Ice Lake微架构开始，Intel支持5级EPT（启用Intel 5-Level Paging时），将EPT扩展到57位GPA空间。5级EPT在PML4之上增加了一级PML5（Page Map Level 5），使用GPA[56:48]（9位）索引。5级EPT将GPA空间从256TB扩展到128PB，但每次EPT遍历需要多读取一个页表项，嵌套遍历的开销进一步增大。

AMD NPT

AMD在2006年发布的Barcelona处理器中引入了Nested Page Tables（NPT），这是AMD-V（AMD Virtualization）框架下的二阶段地址转换机制。NPT的设计理念与Intel EPT基本一致，但在实现细节上有一些差异。

NPT的启用

NPT通过VMCB（Virtual Machine Control Block）中的NP_ENABLE位启用。Hypervisor将嵌套页表的根物理地址（nCR3）写入VMCB的相应字段。与Intel的EPTP不同，AMD的nCR3直接使用CR3的格式——即嵌套页表的结构与Guest和Host的常规页表使用完全相同的格式。

NPT与EPT的差异

NPT和EPT在功能上几乎等价，但有以下值得注意的差异：

页表项格式。NPT使用与常规AMD64页表完全相同的页表项格式，权限位（P、R/W、U/S、NX等）的含义不变。EPT则使用独立的EPTE格式，权限位的编码方式不同。NPT的这一选择简化了页表遍历硬件的设计——Stage-1和Stage-2可以共享同一套页表遍历逻辑。
权限检查。NPT中的U/S位在嵌套翻译中的语义需要特别注意。在NPT上下文中，Guest的所有内存访问（无论Guest处于Ring 0还是Ring 3）在Stage-2翻译中都被视为"用户态"访问。这意味着NPT页表项中的U/S位必须设置为User（1），否则所有Guest内存访问都将失败。
大页支持。NPT和EPT都支持2MB和1GB大页映射。大页在虚拟化环境中特别有价值——使用大页可以显著减少嵌套页表遍历的级数，从而降低翻译开销。我们将在12.2.1 节中详细分析这一优化。

NPT的性能

AMD在NPT的设计中引入了一些针对嵌套遍历的硬件优化。例如，AMD的处理器在NPT遍历过程中会缓存中间级别的翻译结果（即GPA到HPA的中间映射），使得后续遍历相同区域的页表时可以跳过部分Stage-2查找。这种页表遍历缓存（Page Walk Cache）对减少嵌套遍历开销至关重要，我们将在12.2.2 节中进一步讨论。

ARM Stage-2翻译

ARM架构从ARMv7开始引入虚拟化扩展（Virtualization Extensions），在ARMv8-A（AArch64）中进一步完善。ARM的二阶段地址转换机制在概念上与Intel EPT和AMD NPT一致，但在术语和实现细节上有自己的特色。

特权级模型

ARM将异常级别（Exception Level, EL）分为四级：

EL0：用户态应用程序。
EL1：操作系统内核。在虚拟化环境中，Guest OS运行在EL1。
EL2：Hypervisor。Hypervisor运行在EL2，具有对虚拟化控制的完全权限。
EL3：Secure Monitor（安全固件），负责Normal World和Secure World之间的切换。

这种分层设计使得Guest OS仍然运行在EL1（而非降级到EL0），保持了与非虚拟化环境相同的特权级，简化了Guest OS的移植。

VTTBR_EL2

ARM的Stage-2页表基地址存储在VTTBR_EL2（Virtualization Translation Table Base Register at EL2）寄存器中。VTTBR_EL2包含两个关键字段：

BADDR（位[47:1]）：Stage-2翻译表的基物理地址。
VMID（位[63:48]，8位或16位）：虚拟机标识符，用于在TLB中区分不同VM的翻译条目。VMID的宽度由VTCR_EL2.VS位控制：0表示8位VMID（最多256个VM），1表示16位VMID（最多65536个VM）。

Stage-2页表格式

ARM的Stage-2页表使用与Stage-1类似的多级基数树结构，但有以下区别：

翻译粒度。ARM支持4KB、16KB和64KB三种页大小，Stage-2可以使用与Stage-1不同的粒度。例如，Guest OS使用4KB页，而Hypervisor的Stage-2可以使用64KB页来减少页表级数。
IPA宽度。中间物理地址（IPA，即GPA）的宽度由VTCR_EL2.T0SZ字段控制，可以配置为32位到48位。较窄的IPA宽度可以减少Stage-2页表的级数（例如32位IPA只需要2级页表），从而降低嵌套遍历的开销。
权限模型。Stage-2页表的权限检查独立于Stage-1。最终的有效权限是Stage-1和Stage-2权限的交集——只有当两级翻译都允许某种访问时，该访问才能成功。例如，即使Stage-1允许写入，如果Stage-2将该GPA映射为只读，写操作仍然会触发异常。
内存属性组合。Stage-2页表可以覆盖或限制Stage-1指定的内存属性（Cacheable/Non-cacheable、Device memory等）。ARM定义了详细的属性组合规则，确保Hypervisor能够控制Guest对物理内存区域的访问特性。

ARM Stage-2与Intel EPT的关键差异

ARM的Stage-2翻译与Intel EPT在设计哲学上有几个值得注意的差异：

IPA宽度可配置。ARM允许Hypervisor通过VTCR_EL2.T0SZ字段限制IPA的宽度。例如，如果VM只需要32GB的Guest物理地址空间（35位IPA），Hypervisor可以将IPA宽度设为35位，Stage-2页表仅需3级（而非4级或5级）。这直接减少了嵌套遍历的深度——对于35位IPA + 4KB页，Stage-2遍历从4级降到3级，每步Guest页表访问的Stage-2开销从4次降到3次。Intel EPT不支持这种灵活配置——EPT总是使用与Host页表相同的级数（4级或5级）。
这一设计选择反映了ARM在移动和嵌入式领域的经验：移动设备的VM通常内存较小（几百MB到几GB），无需48位或更大的IPA空间。缩短IPA可以在不增加任何硬件的情况下降低虚拟化开销——一种纯软件配置驱动的优化。
三种页粒度选择。ARM支持4KB、16KB和64KB三种基本页粒度，且Stage-1和Stage-2可以使用不同的粒度。例如，Guest OS使用4KB页（精细的内存管理），而Hypervisor的Stage-2使用64KB页（减少页表级数和TLB压力）。这种混合粒度配置在ARM的云服务器（如AWS Graviton、Ampere Altra）上很常见。
权限交集模型。ARM的最终有效权限是Stage-1和Stage-2权限的交集。这比Intel EPT的独立权限检查更严格——即使Guest的Stage-1页表允许某种访问，Hypervisor仍然可以通过Stage-2的限制来覆盖Guest的权限设置。这一模型为安全虚拟化（如机密计算）提供了坚实的基础。

Secure Stage-2翻译

ARMv8.4-A引入了Secure EL2，允许在Secure World中也运行Hypervisor。Secure Stage-2翻译使用VSTTBR_EL2寄存器，为安全虚拟机（如TEE中的可信应用）提供与Normal World相同的二阶段地址翻译功能。这一特性对机密计算（Confidential Computing）场景至关重要——ARM CCA（Confidential Compute Architecture）利用Secure Stage-2翻译为Realm虚拟机提供内存隔离，确保Hypervisor无法读取或篡改Realm VM的内存内容。

VHE：虚拟化宿主扩展

ARMv8.1-A引入了VHE（Virtualization Host Extensions），允许Host OS内核直接运行在EL2而非EL1。这对Type-2 Hypervisor（如KVM）特别有价值——Host Linux内核在EL2运行，Guest OS在EL1运行，避免了Host OS在EL1和Hypervisor在EL2之间频繁切换的开销。VHE通过寄存器重映射实现：当VHE启用时，EL2对TTBR0_EL1、SCTLR_EL1等EL1系统寄存器的访问实际上被重定向到对应的EL2寄存器，使得Host内核无需修改即可在EL2运行。

图图 12.3展示了ARM虚拟化的地址翻译流程——从EL0/EL1中Guest发出的虚拟地址，经过Stage-1（由TTBR0_EL1/TTBR1_EL1指向的页表）翻译为IPA，再经过Stage-2（由VTTBR_EL2指向的页表）翻译为最终的PA。

ARM二阶段地址翻译流程：VA $\to$ IPA（Stage-1）$\to$ PA（Stage-2）

RISC-V H扩展

RISC-V的H扩展（Hypervisor Extension）于2023年在RVA23 Profile中被正式批准，是RISC-V架构支持硬件虚拟化的标准扩展。H扩展引入了新的特权模式和CSR（Control and Status Register），使处理器能够原生支持二阶段地址转换。

特权模式

H扩展在原有的M/S/U三级特权模式之上，引入了两个新的虚拟特权模式：

VS模式（Virtual Supervisor）：Guest OS内核运行在此模式。VS模式是S模式的虚拟化版本——Guest OS认为自己运行在S模式，但实际上是VS模式，其特权操作受到Hypervisor的控制。
VU模式（Virtual User）：Guest中的用户态应用程序运行在此模式。VU模式是U模式的虚拟化版本。

当处理器运行在VS或VU模式时，二阶段地址转换自动生效：VS/VU模式的内存访问首先通过Guest的vsatp CSR指向的Guest页表进行Stage-1翻译（GVA $\to$ GPA），然后通过Hypervisor的hgatp CSR指向的Stage-2页表进行翻译（GPA $\to$ HPA）。

图图 12.4展示了RISC-V H扩展的特权模式层次。

hgatp CSR

hgatp（Hypervisor Guest Address Translation and Protection）是H扩展中最核心的CSR之一。它的格式与satp类似，包含以下字段：

MODE（位[63:60]）：指定Stage-2翻译模式。对于RV64，支持的模式包括Sv39x4、Sv48x4和Sv57x4。"x4"后缀表示Stage-2根页表的大小是Stage-1的4倍（即16KB而非4KB），因为Stage-2的输入地址比Stage-1多2位（GPA空间比VA空间大4倍，以容纳Guest对satp中PPN字段的完整映射）。
VMID（位[57:44]，最多14位）：虚拟机标识符，功能类似于ARM的VMID。VMID的实际宽度由实现决定（VMIDLEN），范围为0到14位。
PPN（位[43:0]）：Stage-2根页表的物理页号。

两级VS/HS CSR

H扩展为Guest上下文引入了一组vs* CSR（如vsatp、vsstatus、vscause等），它们是对应S模式CSR的虚拟化副本。当处理器运行在VS模式时，对satp、sstatus等CSR的访问实际上被重定向到vsatp、vsstatus等VS CSR。这种透明的CSR重映射使得Guest OS无需任何修改即可在虚拟化环境中运行。

同时，H扩展在HS模式（运行Hypervisor的增强S模式）中引入了一组h* CSR用于Hypervisor的虚拟化控制：

hstatus：控制虚拟化相关的处理器状态，包括SPVP（进入VS/VU模式前的特权级）等。
hgatp：Stage-2页表配置（如上所述）。
htval：当Guest发生Page Fault时，记录导致异常的Guest物理地址，帮助Hypervisor快速定位原因。
htinst：记录导致异常的指令编码，使Hypervisor可以在软件中模拟该指令。

HLV/HSV指令

H扩展还引入了HLV（Hypervisor Load from Virtual address）和HSV（Hypervisor Store to Virtual address）指令族，允许Hypervisor在HS模式下直接访问Guest的虚拟地址空间。这些指令的内存访问像在VS/VU模式中一样经过二阶段翻译。这对Hypervisor在处理Guest的Page Fault等异常时非常有用——Hypervisor可以直接读写Guest的内存，无需手动进行地址翻译。

HLV指令族包括HLV.B、HLV.BU、HLV.H、HLV.HU、HLV.W、HLV.WU和HLV.D，分别对应不同宽度的加载操作。HSV指令族包括HSV.B、HSV.H、HSV.W和HSV.D。此外，HLVX.HU和HLVX.WU指令用于以执行权限读取Guest的指令——这在Hypervisor需要解析Guest指令（如模拟特权指令）时特别有用。

HFENCE指令

H扩展定义了两条TLB失效指令用于虚拟化环境：

HFENCE.VVMA：失效Stage-1的TLB条目（GVA $\to$ GPA映射），由Guest OS使用的SFENCE.VMA在VS模式下自动被映射为此指令。Hypervisor也可以主动使用此指令来失效特定VM的Stage-1 TLB条目。
HFENCE.GVMA：失效Stage-2的TLB条目（GPA $\to$ HPA映射）。当Hypervisor修改了Stage-2页表（hgatp指向的页表）后，必须执行此指令来确保TLB中缓存的旧翻译被失效。此指令可以按VMID选择性失效，避免影响其他VM的TLB条目。

RISC-V虚拟化的设计哲学

RISC-V H扩展的设计哲学值得深入探讨。与Intel和AMD的渐进式扩展不同——EPT和NPT是在已有的复杂x86架构上添加虚拟化支持，需要大量的向后兼容考虑——RISC-V H扩展是从零开始设计的，可以吸收Intel/AMD/ARM二十年的虚拟化经验。

为什么RISC-V复用常规PTE格式而非定义独立的Stage-2 PTE？Intel EPT定义了与常规x86-64 PTE不同的EPTE格式（权限位编码不同、无U/S位、有独立的内存类型字段），这带来了两个代价：（1）PTW硬件需要实现两套PTE解析逻辑（常规PTE + EPTE），增加了验证复杂度；（2）操作系统和Hypervisor的页表管理代码需要处理两种PTE格式。RISC-V选择Stage-2复用与Stage-1完全相同的Sv39/Sv48 PTE格式（加上"x4"的根页表扩展），使得同一套PTW硬件和同一套软件页表管理逻辑可以同时服务Stage-1和Stage-2，显著降低了硬件和软件的复杂度。AMD NPT也做了类似的选择——NPT复用常规AMD64 PTE格式。

"x4"根页表的巧妙设计。RISC-V H扩展要求Stage-2的根页表是Stage-1根页表大小的4倍（16KB而非4KB），原因是Stage-2的输入地址（GPA）比Stage-1的输入地址（GVA）多2位——Guest可以在satp的PPN字段中使用完整的物理地址空间，而GPA空间需要容纳所有可能的Guest物理地址。"x4"设计优雅地解决了这一问题，无需增加额外的页表级数。

设计提示

对于正在设计RISC-V处理器的硬件团队，H扩展的PTW实现需要特别注意以下细节：（1）Guest的vsatp中的PPN是一个GPA，PTW在遍历Guest页表之前需要先将这个GPA通过Stage-2翻译为HPA——这是嵌套遍历的"第零步"，容易被遗漏。（2）HFENCE.VVMA和HFENCE.GVMA的实现需要区分Stage-1和Stage-2的TLB条目失效，如果TLB使用Combined设计（缓存GVA $\to$ HPA），则两种HFENCE都可能需要失效同一个条目。（3）htval CSR在Stage-2 Page Fault时应记录触发异常的GPA，这对Hypervisor快速处理EPT Violation至关重要。

案例研究 1 — 四大架构二阶段地址转换特性对比

表表 12.3对比了Intel EPT、AMD NPT、ARM Stage-2和RISC-V H扩展的关键特性。

特性	Intel EPT	AMD NPT	ARM Stage-2	RISC-V H扩展
首次引入	2008, Nehalem	2006, Barcelona	2011, Cortex-A15	2023, RVA23
控制结构	VMCS (EPTP)	VMCB (nCR3)	VTTBR_EL2	hgatp CSR
页表项格式	独立EPTE格式	复用常规PTE	独立Stage-2格式	复用常规PTE
VMID宽度	无（用VPID）	ASID复用	8或16位	最多14位
大页支持	2MB, 1GB	2MB, 1GB	2MB, 1GB, 其他	2MB, 1GB, 其他
5级扩展	5级EPT	5级NPT	可配置	Sv57x4

嵌套页表遍历的开销

二维页表遍历

二阶段地址转换的性能开销远大于简单地将两次单阶段翻译的开销相加。原因在于嵌套——Guest页表遍历的每一步都需要一次完整的Stage-2翻译来将GPA转换为HPA。这使得一次完整的二阶段页表遍历的访存次数呈乘法关系而非加法关系。

最坏情况分析

考虑x86-64架构下的4级页表配置：Guest使用4级页表（PML4 $\to$ PDPT $\to$ PD $\to$ PT），Stage-2也使用4级EPT。一次完整的二阶段地址转换过程如下：

（1）MMU首先需要读取Guest PML4表项。Guest PML4的基地址来自Guest CR3（一个GPA），需要通过4级EPT遍历将其翻译为HPA。这需要4次物理内存访问（读取EPT PML4 $\to$ EPT PDPT $\to$ EPT PD $\to$ EPT PT）来完成Stage-2翻译，再加1次内存访问来读取Guest PML4表项本身。小计： $4 + 1 = 5$ 次。

（2）Guest PML4表项中包含Guest PDPT的基GPA。MMU需要将其通过4级EPT翻译为HPA，然后读取Guest PDPT表项。小计： $4 + 1 = 5$ 次。

（3）Guest PDPT表项中包含Guest PD的基GPA。同样需要4级EPT翻译。小计： $4 + 1 = 5$ 次。

（4）Guest PD表项中包含Guest PT的基GPA。同样需要4级EPT翻译。小计： $4 + 1 = 5$ 次。

（5）Guest PT表项中包含目标数据页的基GPA。最后一次4级EPT翻译将其转换为HPA。小计：4次。

总计： $5 + 5 + 5 + 5 + 4 = 24$ 次物理内存访问。

4级Guest $\times$ 4级EPT的嵌套页表遍历过程：最坏情况下需要24次物理内存访问

逐步分析

为了更具体地理解嵌套遍历的过程，我们以Guest PML4表项的读取（上述步骤1）为例进行详细分析。设Guest CR3中存储的GPA为 $G_0$ ：

MMU将 $G_0$ 送入EPT进行Stage-2翻译。首先读取EPT PML4（地址来自EPTP），使用 $G_0[47:39]$ 索引，读取EPT PML4表项。这是第1次物理内存访问。
EPT PML4表项中包含EPT PDPT的HPA。使用 $G_0[38:30]$ 索引EPT PDPT，读取EPT PDPT表项。第2次物理内存访问。
EPT PDPT表项中包含EPT PD的HPA。使用 $G_0[29:21]$ 索引EPT PD，读取EPT PD表项。第3次物理内存访问。
EPT PD表项中包含EPT PT的HPA。使用 $G_0[20:12]$ 索引EPT PT，读取EPT PT表项，获得 $G_0$ 对应的HPA，记为 $H_0$ 。第4次物理内存访问。
MMU使用 $H_0 + G_0[11:0]$ （页内偏移）从物理内存中读取Guest PML4表项的内容。第5次物理内存访问。

至此，MMU仅仅完成了Guest PML4表项的读取，就已经消耗了5次物理内存访问。Guest PML4表项中包含下一级Guest PDPT的GPA $G_1$ ，接下来还需要以同样的方式对 $G_1$ 进行Stage-2翻译（又是4次EPT遍历）并读取Guest PDPT表项（1次），如此递归直到所有4级Guest页表都遍历完毕。

一般化公式

在第 10.0 章中我们看到，4级页表遍历需要4次内存访问——这是一个线性的 $O(G)$ 开销。现在我们看到，虚拟化将这个线性开销变成了乘法——这正是因为Guest页表本身存储在需要Stage-2翻译的地址空间中。每一次读取Guest页表项（一次GPA访问）都需要一次完整的Stage-2遍历来将GPA转换为HPA。这种"翻译中的翻译"是虚拟化地址转换开销呈乘法增长的根本原因。

设Guest页表为 $G$ 级，Stage-2页表为 $S$ 级，则一次完整的二阶段页表遍历在最坏情况下的物理内存访问次数为：

N_{\text{access}} = G \times (S + 1) + S

其中 $G \times (S + 1)$ 是遍历 $G$ 级Guest页表项的开销（每级需要 $S$ 次EPT遍历加1次读取Guest表项）， $S$ 是最终将目标GPA翻译为HPA的开销。

表表 12.4列出了不同页表级数组合下的最坏情况访存次数。

Guest页表级数 $G$	Stage-2级数 $S$	公式	访存次数
2	2	$2 \times 3 + 2$	8
3	3	$3 \times 4 + 3$	15
3	4	$3 \times 5 + 4$	19
4	4	$4 \times 5 + 4$	24
4	5	$4 \times 6 + 5$	29
5	5	$5 \times 6 + 5$	35

不同Guest/Stage-2页表级数组合下的最坏情况物理内存访问次数

性能分析 1 — 嵌套页表遍历的延迟影响

在一个L2 Cache命中延迟为12周期、LLC命中延迟为40周期、DRAM延迟为200周期的系统中，假设页表遍历中50%的访问命中L2、30%命中LLC、20%需要访问DRAM，则单次物理内存访问的平均延迟为：

t_{\text{avg}} = 0.5 \times 12 + 0.3 \times 40 + 0.2 \times 200 = 6 + 12 + 40 = 58 \text{ 周期}

对于24次访问的最坏情况：

T_{\text{walk}} = 24 \times 58 = 1392 \text{ 周期}

相比之下，非虚拟化环境下的4级页表遍历只需要 $4 \times 58 = 232$ 周期。嵌套遍历的开销是非嵌套的 $24/4 = 6\times$ 。在5 GHz处理器上，1392个周期意味着约278 ns的延迟——这接近于一次DRAM访问的延迟的3 $\sim$ 4倍。

当然，这是完全没有任何缓存命中的最坏情况。在实际系统中，TLB和页表遍历缓存会捕获大量重复的翻译，将平均开销大幅降低。但在工作集较大、TLB命中率较低的虚拟化工作负载中（如数据库、大数据分析、内存密集型科学计算），嵌套页表遍历的开销仍然是一个严重的性能瓶颈。

嵌套遍历中的访问局部性分析

嵌套遍历的实际开销远低于最坏情况，关键原因在于EPT遍历的高度局部性。理解这一点需要观察嵌套遍历中EPT访问的地址分布：

Guest页表通常是由Guest OS集中分配的——一个进程的所有4级页表可能仅占用几百个4KB物理页，这些页面在Guest物理地址空间中往往是聚集的。当PTW遍历不同的Guest页表项时，它们的GPA可能落在相同的EPT区域内——即它们的EPT PML4和PDPT级别映射相同，仅在PD和PT级别不同。

这意味着：

EPT PML4级别：几乎所有嵌套遍历共享同一个EPT PML4表项（因为Guest页表的GPA通常落在同一个512GB区域内）。如果PWC缓存了这个EPT PML4E，所有嵌套遍历的第一步都可以跳过。
EPT PDPT级别：大多数嵌套遍历共享相同的少数几个EPT PDPTE（Guest页表通常在几GB的范围内）。32项的EPT PWC可以覆盖大部分情况。
EPT PD和PT级别：这两级的局部性较差，因为不同Guest页表项可能分散在不同的2MB和4KB范围内。但Data Cache仍然可以缓存最近访问的EPT PDE和PTE。

综合来看，在EPT PWC（缓存PML4和PDPT级别）和Data Cache（缓存PD和PT级别）的协同作用下，典型的EPT遍历实际上只需要0–2次物理内存访问（而非理论最坏的4次）。这将嵌套遍历每步的开销从5次降低到1–3次，总的24次遍历降低到约6–10次有效物理内存访问。

设计提示

理解嵌套遍历的局部性对于处理器设计者有实际指导意义：（1）EPT PWC的PML4级别仅需2–4项即可达到接近100%的命中率，不值得分配更多容量；（2）EPT PWC的PDPT级别是收益最高的投资点——从8项增加到32项可以显著提升命中率；（3）EPT PD/PT级别的缓存可以依赖Data Cache，不需要独立的PWC结构。

5级页表对虚拟化的影响

随着Intel引入5-Level Paging和RISC-V定义Sv57，5级页表正在逐步被采用。如果Guest和Host都使用5级页表，嵌套遍历的最坏情况将达到 $5 \times 6 + 5 = 35$ 次物理内存访问——比4 $\times$ 4的24次增加了近50%。这使得页表遍历缓存和大页映射等优化在5级页表环境下更加重要。

大页对嵌套遍历的优化

使用大页可以有效减少嵌套遍历的开销。如果Guest页表使用2MB大页（跳过最后一级PT），Guest页表遍历只有3级（PML4 $\to$ PDPT $\to$ PD），则最坏情况访存次数降为 $3 \times 5 + 4 = 19$ 次。如果Stage-2的EPT也使用2MB大页映射（3级EPT），则进一步降为 $3 \times 4 + 3 = 15$ 次。如果Guest使用1GB大页（2级Guest遍历）且Stage-2也使用1GB大页（2级EPT），则仅需 $2 \times 3 + 2 = 8$ 次——与非虚拟化环境下4级页表遍历的4次接近。

Page Shattering：大页的逆过程

大页在虚拟化环境中的优势巨大，但Hypervisor在某些操作中被迫将2MB或1GB大页拆分为4KB小页——这称为Page Shattering（页面碎片化）。触发Page Shattering的典型场景包括：

脏页跟踪（Live Migration）：在VM实时迁移过程中，Hypervisor需要追踪哪些4KB粒度的页面被Guest修改过（脏页），以便仅传输脏页到目标主机。如果Stage-2使用2MB大页映射，Hypervisor无法区分2MB区域内哪些4KB页是脏的——必须将整个2MB传输到目标，浪费带宽。因此Hypervisor将2MB大页拆分为512个4KB小页，对每个小页设置写保护，Guest写入时触发EPT Violation，Hypervisor记录该4KB页为脏页。
内存气球回收（Ballooning）：当物理内存紧张时，Hypervisor通过气球驱动（如virtio-balloon）回收Guest的部分内存。如果被回收的页面位于一个2MB大页映射的中间，Hypervisor必须拆分大页，仅解除被回收的4KB页的映射。
内存去重（KSM）：内核相同页合并（Kernel Same-page Merging）将多个VM中内容相同的4KB页映射到同一个物理帧。被合并的页需要从大页映射中拆出。
VM快照：本章开篇的案例正是这一场景——快照操作需要追踪Guest的脏页，触发大规模Page Shattering。

Page Shattering对TLB性能的影响是灾难性的。以本章开篇案例为例：一台服务器上64个VM原本使用2MB大页映射，L2 sTLB（2048项）的有效Reach为 $2048 \times 2\text{MB} = 4\text{GB}$ 。Page Shattering后所有映射变为4KB页，有效Reach骤降到 $2048 \times 4\text{KB} = 8\text{MB}$ ——降低了512倍。64个VM同时争夺8MB的TLB Reach，每个VM仅有 $8\text{MB}/64 = 128\text{KB}$ 的有效覆盖范围，TLB thrashing不可避免。

设计提示

在虚拟化环境中，Hypervisor应当尽可能使用大页来建立Stage-2映射。对于Guest占用的大块连续内存区域（如Guest RAM的主体部分），使用1GB大页映射可以将Stage-2页表遍历从4级减少到2级，显著降低嵌套遍历的开销。许多Hypervisor（如KVM、Xen）都实现了自动大页合并（transparent huge page coalescing）机制，在Stage-2层面将多个4KB页合并为2MB或1GB大页。

嵌套TLB

尽管嵌套页表遍历的最坏情况开销巨大，但在实际系统中，硬件通过多层缓存机制大幅降低了平均翻译开销。除了常规的TLB（缓存VA $\to$ PA的完整翻译结果），虚拟化环境下还需要额外的缓存结构来加速嵌套翻译。

TLB中缓存GVA到HPA的映射

在第 11.0 章中我们分析了TLB的CAM功耗随条目数线性增长。虚拟化环境下TLB条目需要额外的VMID字段（8–16位），这不仅增加了每条目的存储位宽，还增加了CAM匹配逻辑的比较宽度——以72项L1 dTLB为例，增加16位VMID使得每次查找的CAM翻转位从 $72 \times 48 = 3456$ 位增加到 $72 \times 64 = 4608$ 位，功耗增加约33%。这是虚拟化对TLB硬件设计的一个不可忽视的代价。

在虚拟化环境中，TLB可以直接缓存GVA到HPA的最终翻译结果，而不仅仅是GVA到GPA的Stage-1翻译结果。这样，当TLB命中时，一次查找就可以直接获得Host物理地址，完全跳过两级页表遍历。TLB条目需要同时使用ASID（进程标识）和VMID（虚拟机标识）来标记，以区分不同VM中不同进程的翻译。

GPA到HPA的缓存

除了缓存最终的GVA $\to$ HPA映射，处理器还可以在TLB或专用缓存结构中缓存GPA $\to$ HPA的Stage-2翻译结果。这种缓存的价值在于：当发生TLB Miss需要进行嵌套页表遍历时，Guest页表遍历每一步都需要一次GPA $\to$ HPA的Stage-2翻译。如果这些Stage-2翻译能够在GPA $\to$ HPA缓存中命中，就可以跳过4级EPT遍历，将每步的开销从5次访存（4次EPT遍历 + 1次读取Guest表项）降低到1 $\sim$ 2次。

页表遍历缓存

页表遍历缓存（Page Walk Cache, PWC）在虚拟化环境中的作用更加关键。PWC缓存页表遍历的中间结果——例如，它可以缓存PML4表项和PDPT表项的内容，使得后续遍历同一页表区域时可以直接从PWC中获取中间级别的翻译结果，跳过前几级遍历。

在嵌套遍历中，PWC可以同时缓存Guest页表和EPT的中间结果。例如：

Guest PWC：缓存Guest PML4/PDPT/PD表项的GPA $\to$ 内容映射。当两次GVA翻译共享同一个Guest PML4表项时，第二次翻译可以直接从Guest PWC中获取PDPT的GPA，跳过Guest PML4的读取。
EPT PWC：缓存EPT PML4/PDPT/PD表项的GPA $\to$ HPA映射。由于嵌套遍历中大量的EPT查找都集中在相同的EPT页表区域（Guest页表通常位于连续的物理地址区域），EPT PWC可以捕获大量重复的Stage-2翻译。

案例研究 2 — Intel Skylake的嵌套翻译缓存层次

Intel Skylake微架构为虚拟化环境实现了多层翻译缓存：

L1 DTLB：64项全相联，缓存GVA $\to$ HPA的最终映射。使用VPID（Virtual Processor ID）和PCID区分不同VM和进程。4KB和2MB页各有独立的TLB分区。
L2 STLB：1536项，12-way组相联，缓存GVA $\to$ HPA映射。支持4KB和2MB页。
页表遍历缓存（PWC）：缓存Guest和EPT页表的中间级别翻译结果。Skylake的PWC有4个级别，分别缓存PML4、PDPT、PD和PT级别的翻译。
EPT缓存：专门缓存GPA $\to$ HPA的Stage-2翻译，在页表遍历过程中使用。

通过这些缓存层次的协同工作，在典型的虚拟化工作负载中，绝大多数地址翻译可以在L1 TLB或L2 STLB中命中，无需进行完整的嵌套遍历。即使发生TLB Miss，PWC和EPT缓存也能大幅减少实际的物理内存访问次数。Intel的测量数据表明，EPT带来的性能开销在大多数工作负载中不超过5% $\sim$ 10%，远低于理论最坏情况的 $6\times$ 。

VMID与TLB效率

在虚拟化环境中，物理机上同时运行着多个VM，每个VM中又有多个进程。如果没有适当的标记机制，每次VM切换（vCPU调度）时都需要刷新（flush）整个TLB，因为TLB中缓存的翻译属于前一个VM，对新调度的VM是无效的。TLB刷新的代价非常高——一个拥有上千项的L2 TLB在刷新后需要数百乃至上千次TLB Miss才能重新预热，这对性能的影响是灾难性的。

VMID的作用

VMID（Virtual Machine Identifier）是分配给每个VM的唯一标识符，存储在TLB条目中。TLB查找时，当前运行的VM的VMID被作为匹配条件之一——只有VMID与当前VM匹配的TLB条目才会被报告为命中。这样，不同VM的TLB条目可以同时共存于TLB中，VM切换时无需刷新TLB。

VMID与ASID（Address Space Identifier）的配合形成了二级标记：VMID区分VM，ASID区分同一VM中的不同进程。一个TLB条目的完整标记为（VMID, ASID, VPN），只有三者都匹配时才报告命中。

VMID的宽度

VMID的宽度决定了可以同时在TLB中区分的VM数量：

ARM：支持8位或16位VMID（256或65536个VM）。8位VMID对于大多数场景已经足够——一台物理服务器上同时活跃的VM数量通常不超过256个。16位VMID为容器化环境（每个容器可以分配一个独立的VMID）提供了足够的空间。
RISC-V：VMID宽度由实现决定，最多14位（16384个VM）。较小的实现可以只提供6 $\sim$ 8位VMID。
Intel：使用16位VPID（Virtual Processor ID）来标记TLB条目。VPID在功能上与VMID类似，但标记的粒度是虚拟处理器（vCPU）而非VM。由于一个VM可能有多个vCPU，VPID的空间需要大于VM数量。
AMD：AMD Zen系列处理器使用ASID字段来同时标记VM和进程——Hypervisor为每个VM分配一个或多个ASID值。

VMID回收与TLB失效

当VMID空间耗尽时（即所有VMID都已分配但仍有新VM需要启动），Hypervisor需要回收一个已分配的VMID并将其重新分配给新VM。回收VMID时，必须确保TLB中属于旧VM的所有条目被失效：

全局刷新：最简单的方法是刷新整个TLB。这一操作代价高昂，但实现简单。在VMID空间足够大（如16位）的情况下，回收很少发生，全局刷新的摊销成本可以忽略。
按VMID选择性刷新：只刷新TLB中属于被回收VMID的条目。这需要TLB支持按VMID匹配的批量失效操作。ARM的TLBI VMALLE1IS指令可以失效指定VMID的所有Stage-1 TLB条目；RISC-V的HFENCE.GVMA指令提供类似的功能。
Generation-based方案：维护一个全局的generation计数器。每次分配VMID时递增generation。TLB条目中同时存储VMID和generation。TLB查找时，只有VMID和generation都匹配才报告命中。回收VMID时只需递增generation，无需刷新TLB。这种方案在Hypervisor软件中常见，但需要处理generation溢出的边界情况。

VMID回收的频率分析。VMID回收频率取决于VMID宽度和系统中VM的动态行为。以8位VMID（256个）为例：如果一台服务器上运行200个VM（每个分配一个VMID），剩余56个VMID作为缓冲。每次新VM创建（如容器启动）需要一个新VMID。在容器化部署中，短生命周期的容器可能每分钟创建/销毁数十个，56个缓冲VMID可能在几分钟内耗尽，之后每次容器创建都触发VMID回收和TLB失效。

在16位VMID（65536个）的配置下，即使每秒创建10个新容器， $65536 - 200 = 65336$ 个空闲VMID可以使用 $65336/10 \approx 109$ 分钟后才需要第一次回收——几乎不会发生。这就是为什么ARM和RISC-V都支持较宽的VMID（16位和14位）——为容器化和微服务的高VM周转率提供足够的缓冲。

设计权衡 2 — VMID宽度的选择

VMID的宽度需要在硬件成本和软件复杂度之间权衡：

更宽的VMID（如16位）可以支持更多的并发VM，减少VMID回收的频率，但每个TLB条目需要额外的存储位，增加TLB的面积和功耗。对于一个1536项的L2 TLB，8位VMID需要 $1536 \times 8 = 12288$ 位（1.5 KB）的额外存储；16位VMID则需要3 KB。
更窄的VMID（如6 $\sim$ 8位）节省硬件成本，但在VM数量较多时VMID回收更频繁，导致更多的TLB失效和性能下降。
在实践中，8 $\sim$ 16位VMID是一个良好的平衡点。大多数物理服务器上同时活跃的VM不超过几百个，8位VMID（256个）通常足够。在大规模容器化部署场景中，14 $\sim$ 16位VMID更为合适。

TLB分区策略

在虚拟化环境中，TLB的有效利用率还取决于分区策略。如果多个VM共享同一个物理核心（通过vCPU时分复用），TLB中的条目被这些VM瓜分。假设一个L2 TLB有1536项，物理核心上有4个活跃VM的vCPU在交替运行，则每个VM平均只能使用约384项TLB条目——远少于非虚拟化环境下单个OS可以使用的全部1536项。

这种TLB容量稀释效应是虚拟化环境下TLB Miss率升高的重要原因之一。增大TLB容量、使用大页映射以及减少不必要的VM切换，都是缓解这一问题的有效手段。

大页如何缓解容量稀释

TLB Reach（TLB覆盖范围）是分析容量稀释的关键指标。TLB Reach = TLB条目数 $\times$ 页大小。在虚拟化环境中，每个VM的有效TLB Reach为：

\text{Reach}_{\text{eff}}(N) = \frac{C}{N} \times \text{page\_size}

以L1 dTLB 72项、4个VM为例：

4KB页： $\text{Reach}_{\text{eff}} = 18 \times 4\text{KB} = 72\text{KB}$ ——几乎无法覆盖任何有意义的工作集。
2MB页： $\text{Reach}_{\text{eff}} = 18 \times 2\text{MB} = 36\text{MB}$ ——足以覆盖大多数数据库索引的热集。
1GB页： $\text{Reach}_{\text{eff}} = 18 \times 1\text{GB} = 18\text{GB}$ ——可以覆盖整个虚拟机的内存分配。

大页缓解容量稀释的效果可以用以下公式量化。假设工作集大小为 $W$ ，TLB缺失率近似与TLB Reach不足的部分成正比：

r_{\text{miss}} \propto \max\left(0,\; 1 - \frac{\text{Reach}_{\text{eff}}}{W}\right)

对于 $W = 100\text{MB}$ 的工作集：

4KB页，4 VM： $r \propto 1 - 72\text{KB}/100\text{MB} \approx 1.0$ （接近100%缺失）。
2MB页，4 VM： $r \propto 1 - 36\text{MB}/100\text{MB} = 0.64$ （约64%缺失，但L2 sTLB可以进一步降低）。
2MB页，1 VM（裸机）： $r \propto 1 - 144\text{MB}/100\text{MB} = 0$ （TLB Reach超过工作集，理论0缺失）。

这个分析解释了为什么虚拟化环境下大页的价值远超裸机环境：在裸机上，即使4KB页的TLB Reach（288KB）对于许多桌面工作负载已经足够，大页的收益有限；但在虚拟化环境下，容量稀释将有效Reach进一步缩小到72KB，大页成为维持可用TLB性能的必需品而非可选优化。

硬件描述 1 — 虚拟化环境下的硬件页表遍历器

虚拟化环境对硬件页表遍历器（Hardware Page Table Walker, PTW）的设计提出了更高的要求。非虚拟化环境下的PTW只需要执行线性的多级页表遍历（如4次顺序访存），而虚拟化环境下的PTW需要执行嵌套遍历——每一步Guest页表访问都可能触发一次完整的Stage-2遍历。

现代处理器的PTW通常采用状态机实现，状态包括：

IDLE：等待TLB Miss触发遍历请求。
GUEST_WALK：正在遍历Guest页表的某一级。每一级需要先对GPA执行Stage-2翻译。
STAGE2_WALK：正在遍历Stage-2页表以翻译当前的GPA。这是一个嵌套状态——STAGE2_WALK完成后返回GUEST_WALK继续下一步。
COMPLETE：遍历完成，将最终的HPA写入TLB。

为了提高嵌套遍历的性能，PTW中通常集成了专用的Stage-2 TLB（也称为Nested TLB），用于缓存GPA $\to$ HPA的映射。PTW在GUEST_WALK状态需要翻译GPA时，首先查询Stage-2 TLB：如果命中，可以直接获得HPA，跳过整个STAGE2_WALK过程；如果缺失，才进入STAGE2_WALK执行完整的Stage-2遍历。

一些高性能处理器（如AMD Zen 4、Apple M系列）支持多个并发的PTW请求——当一个遍历正在等待内存响应时，PTW可以开始处理下一个TLB Miss请求。这对虚拟化环境尤其重要，因为嵌套遍历的延迟更长，并发处理可以有效隐藏延迟、提高吞吐量。

Combined TLB vs Split TLB的硬件设计

在虚拟化环境下，TLB可以采用两种根本不同的架构来缓存翻译结果：Combined TLB和Split TLB。这一选择对TLB的命中延迟、容量利用率和失效策略都有深远影响。

Combined TLB

Combined TLB（也称为Flat TLB或Direct TLB）直接缓存GVA $\to$ HPA的最终翻译结果。一次TLB命中即可直接获得Host物理地址，无需任何中间翻译步骤。TLB条目的标记（tag）由三元组（VMID, ASID, VPN）组成，值为HPA及权限属性。

Combined TLB的优势在于命中时的极低延迟：与非虚拟化环境下的TLB查找完全相同，仅增加了VMID的比较宽度。在第 11.0 章中我们看到，TLB查找位于所有Cache访问的关键路径上，1周期的命中延迟是硬性要求——Combined TLB完美满足这一需求。

Combined TLB的主要缺陷是容量利用率低。每个TLB条目绑定了特定的（VM, 进程, 虚拟页）三元组，不同VM甚至同一VM的不同进程之间无法共享条目。如果物理核心上有4个活跃VM的vCPU在时分复用，TLB的有效容量被四分。更糟糕的是，即使两个VM的Guest OS将不同的GVA映射到同一个HPA（例如共享的只读代码页），Combined TLB中仍然需要两个独立的条目——因为它们的GVA不同。

Split TLB

Split TLB将翻译过程分为两个独立的缓存层级：

Stage-1 TLB：缓存GVA $\to$ GPA的映射，使用（VMID, ASID, VPN）作为标记。
Stage-2 TLB：缓存GPA $\to$ HPA的映射，使用（VMID, GPN）作为标记（GPN = Guest Physical Page Number）。

一次完整的地址翻译需要两步TLB查找：先在Stage-1 TLB中将GVA翻译为GPA，再在Stage-2 TLB中将GPA翻译为HPA。

Split TLB的优势在于Stage-2条目可以跨VM进程共享。同一VM中不同进程的GVA虽然不同，但它们经过Stage-1翻译后可能指向相同的GPA。Stage-2 TLB中一个GPA $\to$ HPA的条目可以服务同一VM中所有进程的Stage-2翻译需求。此外，如果Hypervisor为不同VM的共享内存区域（如KSM去重后的只读页）分配了相同的HPA映射模式，Stage-2条目的复用率进一步提高。

Split TLB的缺陷是串行查找的延迟开销。两次TLB查找需要串行执行——Stage-2查找必须等待Stage-1的GPA结果。如果每次TLB查找需要1周期，总延迟为2周期，直接增加了Load-to-Use延迟。在对延迟极度敏感的L1 TLB中，这一额外周期通常不可接受。

混合方案：Combined + 辅助Stage-2 Cache

现代处理器采用的混合方案结合了两者的优势：

主TLB（L1 dTLB、L2 sTLB）采用Combined设计，直接缓存GVA $\to$ HPA，保证命中时的最低延迟。
PTW内部集成一个专用的Stage-2 TLB（或EPT Cache），缓存GPA $\to$ HPA的映射。当Combined TLB Miss触发嵌套页表遍历时，PTW先查询内部的Stage-2 TLB：如果GPA在Stage-2 TLB中命中，可以跳过完整的Stage-2遍历（省去4次EPT查找），直接获得HPA。

这种混合方案使得：（1）绝大多数地址翻译在Combined TLB中以1周期延迟命中；（2）TLB Miss时，嵌套遍历的开销通过Stage-2 Cache大幅降低——每一步Guest页表访问从 $4+1=5$ 次内存访问降低到 $0+1=1$ 次（Stage-2 Cache命中时）。

Combined TLB + Stage-2 Cache（左）vs Split TLB（右）的架构对比

::: tradeoff 设计权衡 3 — Combined TLB与Split TLB的设计权衡

Combined TLB：命中延迟最低（1周期），实现简单；但容量利用率低——每个条目绑定特定VM和进程，多VM环境下有效容量被稀释。Intel、AMD、ARM的主流处理器均采用Combined设计。
Split TLB：Stage-2条目可跨进程共享，容量利用率更高；但命中路径需要串行两次查找，延迟翻倍。在延迟不敏感的场景（如IOMMU内部的TLB）中，Split设计可能更优。
混合方案：是当前的工程最优解。Combined TLB保证快速路径的延迟，PTW内部的Stage-2 Cache加速慢速路径的嵌套遍历。代价是需要额外的Stage-2 Cache面积（通常为32–128项的小容量缓存）。

:::

虚拟化环境下TLB容量稀释的定量分析

在虚拟化环境中，物理核心上的多个VM共享同一个TLB。VMID标签使得不同VM的TLB条目可以共存，但TLB的总容量是固定的——当更多VM的条目涌入TLB时，每个VM可用的有效TLB容量减少。这种容量稀释效应是虚拟化环境下TLB缺失率升高的主要原因之一。

稀释公式

设TLB总容量为 $C$ 项，物理核心上有 $N$ 个活跃VM的vCPU在时分复用。在最坏情况下（所有VM的工作集大小相同且无共享映射），每个VM的有效TLB容量约为：

C_{\text{eff}}(N) \approx \frac{C}{N}

实际情况通常好于最坏情况，因为：（1）不同VM的活跃度不均匀——某些VM可能处于I/O等待或空闲状态，其TLB条目被其他活跃VM逐步替换；（2）Hypervisor通常为每个物理核心分配少量vCPU（如2–4个），而非数十个；（3）大页映射可以用更少的TLB条目覆盖同样大小的工作集。

容量稀释对AMAT的影响

在第 11.0 章中，我们推导了TLB的AMAT公式。现在将容量稀释效应纳入分析：

性能分析 2 — 虚拟化环境下TLB有效AMAT的五步算例

Setup. 计算4个VM共享一个物理核心时，虚拟化环境下地址翻译的有效AMAT。处理器配置：L1 dTLB 72项、L2 sTLB 2048项。非虚拟化基线：L1缺失率 $r_1 = 1\%$ ，L2条件缺失率 $r_2 = 10\%$ ，PTW延迟35周期。

Strategy. 首先计算容量稀释后的有效TLB容量和缺失率，然后计算虚拟化环境下PTW的嵌套遍历延迟，最终得到有效AMAT。

Derivation.

有效TLB容量：4个VM共享，L1有效容量 $\approx 72/4 = 18$ 项，L2有效容量 $\approx 2048/4 = 512$ 项。
稀释后缺失率：TLB缺失率与TLB Reach成反比。L1 Reach从 $72 \times 4\text{KB} = 288\text{KB}$ 降到 $18 \times 4\text{KB} = 72\text{KB}$ 。假设工作集为1MB，稀释后L1缺失率 $r_1' \approx 4\%$ （从1%增长到4%，因为Reach减少了4倍）。L2条件缺失率 $r_2' \approx 25\%$ （从10%增长，L2 Reach从8MB降到2MB）。
嵌套PTW延迟：虚拟化环境下PTW需要嵌套遍历。假设Stage-2 Cache命中率为70%，则平均嵌套PTW延迟 $T_{\text{PTW}}' = 0.30 \times 24 \times 58 + 0.70 \times 6 \times 58 = 418 + 244 = 662$ 周期。（这里简化计算：Stage-2 Cache全Miss时24次访问 $\times$ 58周期/次，全命中时约6次 $\times$ 58周期/次。）
更精确的估算：考虑PWC对Guest级别的缓存，实际PTW延迟约 $T_{\text{PTW}}' \approx 200$ 周期（PWC和Stage-2 Cache协同作用）。
有效AMAT：

\text{AMAT}_{\text{virt}} = 0 + 0.04 \times (6 + 0.25 \times 200) = 0.04 \times 56 = 2.24 \text{ 周期}

Interpretation. 非虚拟化基线的AMAT为0.095周期，虚拟化后AMAT增加到2.24周期——增长了约24倍。如果使用2MB大页：L1有效Reach变为 $18 \times 2\text{MB} = 36\text{MB}$ ， $r_1' \approx 0.1\%$ ；同时嵌套PTW延迟因大页减少遍历级数而降低到约100周期。此时 $\text{AMAT}_{\text{virt}} = 0.001 \times (6 + 0.25 \times 100) = 0.032$ 周期——几乎回到非虚拟化水平。

Verification. VMware的技术白皮书（"Large Pages and Virtualization Performance"）报告大页可将虚拟化环境下的TLB相关性能开销降低75–90%，与我们的计算定性一致。

VM-Exit/VM-Entry与地址转换

虚拟化环境中，当Guest执行某些敏感操作或发生特定事件时，处理器控制权从Guest模式转移到Hypervisor——这称为VM-Exit。Hypervisor处理完事件后，通过VM-Entry将控制权交还Guest。VM-Exit/Entry是虚拟化开销的主要来源之一，其延迟直接影响虚拟化的整体性能。

VM-Exit的完整流程

一次VM-Exit涉及以下硬件操作：

保存Guest状态：处理器将Guest的寄存器状态（通用寄存器、控制寄存器、段寄存器等）保存到VMCS（Intel）或VMCB（AMD）结构中。
加载Host状态：从VMCS/VMCB中加载Host（Hypervisor）的寄存器状态，包括CR3（页表根指针）、RSP（栈指针）、RIP（指令指针）等。
地址空间切换：将页表从Guest的GVA $\to$ GPA $\to$ HPA三级翻译切换为Host的VA $\to$ PA单级翻译。这涉及切换CR3（或TTBR/satp），以及可能的TLB操作。
更新处理器模式：从Guest模式切换到Host模式（如ARM从EL1切换到EL2，RISC-V从VS模式切换到HS模式）。
记录退出原因：将VM-Exit的原因（如EPT Violation、I/O指令、中断等）写入VMCS/VMCB的退出信息字段。

整个VM-Exit过程在现代处理器上需要500–2000个时钟周期，具体取决于微架构和退出原因。Intel Skylake的测量数据显示，一次轻量级VM-Exit（如CPUID指令触发的退出）约500–700周期，而复杂退出（如EPT Violation需要完整的状态保存）约1000–1500周期。AMD Zen系列的VM-Exit延迟通常略低于Intel，约400–1000周期，这得益于VMCB结构的设计优化。

地址转换事件触发的VM-Exit

以下与地址转换相关的事件会触发VM-Exit：

EPT Violation（Intel）/ Nested Page Fault（AMD）/ Stage-2 Abort（ARM）：当Guest的内存访问在Stage-2翻译中遇到权限违规或映射不存在时触发。Hypervisor需要处理这一事件——例如建立Stage-2映射（如果是按需分配）、实施写时复制（CoW）、或进行内存热迁移的脏页跟踪。这是虚拟化环境中最频繁的VM-Exit原因之一。
Guest CR3修改（x86）：在不启用EPT/NPT的旧式影子页表模式下，Guest修改CR3（切换页表）会触发VM-Exit，Hypervisor需要同步更新影子页表。启用EPT/NPT后，Guest的CR3修改不再触发VM-Exit，因为硬件直接处理二阶段翻译。
INVEPT/INVVPID（Intel）：Guest或Hypervisor执行EPT/VPID相关的TLB失效指令时可能触发VM-Exit，取决于VMCS中的控制位配置。
HFENCE指令（RISC-V）：Guest OS在VS模式中执行SFENCE.VMA时被映射为HFENCE.VVMA，通常不触发VM-Exit（硬件直接执行）。但在某些实现中，如果需要Hypervisor介入失效过程，可能配置为触发VM-Exit。

VPID/VMID如何消除VM-Exit时的TLB刷新

在没有VPID/VMID机制的早期虚拟化实现中，每次VM-Exit和VM-Entry都需要完全刷新TLB——因为Host和Guest使用不同的地址空间，TLB中的Guest条目对Host是无效的（反之亦然）。

案例研究 3 — Intel VPID消除VM-Exit TLB刷新——以Skylake为例

Intel在2008年的Nehalem中引入了VPID（Virtual Processor Identifier）。VPID是一个16位标识符，分配给每个vCPU。TLB条目在存储时同时携带VPID标签。TLB查找时，只有VPID与当前运行的vCPU匹配（或条目为Host所有，VPID=0）的条目才报告命中。

VPID的引入使得VM-Exit/Entry时无需刷新TLB——Guest的TLB条目（带有Guest的VPID标签）在切换到Host后自动不可见（因为Host使用VPID=0），切换回Guest后又自动重新可见。这一优化的效果极为显著：

无VPID：每次VM-Exit刷新TLB，假设L2 sTLB有1536项，重新预热需要约1536次TLB Miss，每次约30周期（L2 Cache命中），总预热开销约46000周期。如果VM-Exit频率为每秒10000次，则TLB刷新的开销为 $10000 \times 46000 = 4.6 \times 10^8$ 周期/秒——在5GHz处理器上占用约9.2%的处理能力。
有VPID：VM-Exit/Entry不刷新TLB，TLB预热开销为零。唯一的额外开销是TLB条目中增加了16位VPID标签的存储和比较，对面积和功耗的影响可忽略。

Intel Skylake的实测数据表明，启用VPID后，VM-Exit/Entry的总延迟降低了约40%（从约1200周期降低到约700周期），因为处理器不再需要执行TLB刷新操作。在频繁VM-Exit的工作负载中（如I/O密集型虚拟机），VPID的启用可以将整体虚拟化开销降低15–25%。

VM-Exit频率与IPC的关系

VM-Exit对性能的影响可以通过以下公式量化：

\text{IPC}_{\text{virt}} = \frac{\text{IPC}_{\text{bare}}}{1 + f_{\text{exit}} \times C_{\text{exit}} / \text{CPI}_{\text{bare}}}

其中 $f_{\text{exit}}$ 是每条指令的VM-Exit频率， $C_{\text{exit}}$ 是每次VM-Exit的周期开销（包括Exit + 处理 + Entry）， $\text{CPI}_{\text{bare}}$ 是裸机的CPI。

VM-Exit延迟的历史演进。各代处理器在VM-Exit/Entry延迟上持续优化：

Intel Prescott（2005，首代VT-x）：VM-Exit约4000–6000周期。
Intel Merom/Penryn（2007–2008）：约2000–3000周期。
Intel Nehalem（2008，引入EPT）：约1000–1500周期。
Intel Skylake/Cascade Lake（2015–2019）：约700–1000周期。
Intel Sapphire Rapids（2023）：约500–800周期。
AMD Zen 3/4（2021–2022）：约400–700周期。

从4000+周期降低到500周期以下，每一代的优化都来自于VMCS/VMCB结构的硬件加速——更多的状态保存/恢复操作被硬件并行化，更多的控制字段检查被流水线化。AMD的VMCB设计（一个简单的内存中的数据结构，由VMLOAD/VMSAVE指令批量操作）在Exit/Entry延迟上通常优于Intel的VMCS（一个更复杂的、由VMREAD/VMWRITE逐字段操作的结构）。

例如，如果裸机IPC = 3.0（CPI = 0.333），每1000条指令发生1次VM-Exit（ $f_{\text{exit}} = 0.001$ ），每次VM-Exit开销为1000周期（ $C_{\text{exit}} = 1000$ ）：

\text{IPC}_{\text{virt}} = \frac{3.0}{1 + 0.001 \times 1000 / 0.333} = \frac{3.0}{1 + 3.0} = 0.75

IPC从3.0降到0.75——下降了75%！这个极端例子说明了为什么减少VM-Exit频率是虚拟化性能优化的第一要务。在现代硬件辅助虚拟化中，典型的VM-Exit频率远低于每1000条指令一次（通常为每10万–100万条指令一次），因此实际的IPC下降通常在5–15%以内。

机密计算与地址转换

2020年代兴起的机密计算（Confidential Computing）对虚拟化地址转换提出了新的安全需求。传统虚拟化中，Hypervisor是可信计算基（TCB）的一部分——Hypervisor可以访问Guest VM的所有内存内容。但在机密计算模型中，Guest VM的内存必须对Hypervisor不可见——即使Hypervisor被攻破，攻击者也无法读取Guest的敏感数据。

这一安全目标对地址转换有深远的影响：

Intel TDX（Trust Domain Extensions）：引入了SEPT（Secure EPT），由硬件（TDX Module）而非Hypervisor管理。Hypervisor可以请求为TD（Trust Domain）分配或回收物理页，但不能直接读取TD内存或修改SEPT映射。SEPT的遍历由TDX Module中的安全代码执行，确保Hypervisor无法通过操纵EPT来窃取TD数据。SEPT增加了嵌套遍历的延迟——TDX Module的访问控制检查在每次遍历中增加约10–20周期。
AMD SEV-SNP（Secure Encrypted Virtualization - Secure Nested Paging）：在NPT的基础上增加了RMP（Reverse Map Table），RMP是一个由硬件维护的物理页所有权表，记录每个物理页属于哪个VM。当PTW遍历NPT获得HPA后，硬件还需要查询RMP来验证该物理页确实属于当前VM——如果不属于，访问被拒绝。RMP查询增加了约1次额外的内存访问。
ARM CCA（Confidential Compute Architecture）：通过Realm概念实现机密计算。Realm VM的内存通过GPT（Granule Protection Table）进行物理页级别的隔离。GPT在Stage-2翻译之后进行访问控制检查，确保Realm的物理页不被Normal World的Hypervisor访问。

这些机密计算扩展的共同特点是在地址转换路径上增加了额外的安全检查步骤——无论是SEPT的安全遍历、RMP查询还是GPT检查，都增加了TLB Miss时的处理延迟。在安全性与性能的权衡中，处理器设计者需要确保安全检查不会成为关键路径上的瓶颈。一种常见的优化是为安全检查结果引入专门的缓存（如RMP Cache），使得后续对同一物理页的访问可以跳过完整的表查询。

PTW嵌套遍历的SystemVerilog实现

为了将嵌套页表遍历从概念转化为硬件描述，我们给出一个简化的PTW嵌套遍历状态机。这个状态机体现了Combined TLB + Stage-2 Cache的混合架构：在GUEST_WALK状态中遇到GPA需要翻译时，先查询Stage-2 TLB，命中则跳过整个STAGE2_WALK阶段。数学上，嵌套遍历的状态转换可以表示为一个状态图，其中STAGE2_WALK是GUEST_WALK的嵌套子状态：

verilog

module nested_ptw (
    input  logic        clk, rst_n,
    // TLB Miss触发
    input  logic        tlb_miss,
    input  logic [47:0] miss_gva,
    input  logic [15:0] miss_vmid,
    input  logic        virt_mode,  // 1=虚拟化模式
    // 内存接口
    output logic        mem_req,
    output logic [51:0] mem_addr,   // HPA
    input  logic        mem_ack,
    input  logic [63:0] mem_data,
    // Stage-2 TLB查询
    output logic [47:0] s2tlb_query_gpa,
    input  logic        s2tlb_hit,
    input  logic [51:0] s2tlb_hpa,
    // TLB填充输出
    output logic        fill_valid,
    output logic [47:0] fill_gva,
    output logic [51:0] fill_hpa,
    output logic [5:0]  fill_attr
);

  typedef enum logic [2:0] {
    IDLE,
    GUEST_WALK,      // 正在遍历Guest页表
    S2_QUERY,        // 查询Stage-2 TLB
    STAGE2_WALK,     // Stage-2 TLB未命中，遍历EPT
    READ_GUEST_PTE,  // 读取Guest页表项
    COMPLETE
  } state_t;

  state_t state, next_state;
  logic [2:0]  guest_level;   // Guest遍历当前级数 (0=PML4)
  logic [2:0]  s2_level;      // Stage-2遍历当前级数
  logic [51:0] guest_pte_gpa; // 当前Guest PTE的GPA
  logic [51:0] guest_pte_hpa; // 翻译后的HPA
  logic [51:0] eptp_base;     // EPT根表HPA

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n)
      state <= IDLE;
    else
      state <= next_state;
  end

  always_comb begin
    next_state = state;
    mem_req = 1'b0;
    fill_valid = 1'b0;

    case (state)
      IDLE: begin
        if (tlb_miss)
          next_state = virt_mode ? S2_QUERY : GUEST_WALK;
      end

      S2_QUERY: begin
        // 用当前Guest PTE的GPA查询Stage-2 TLB
        s2tlb_query_gpa = guest_pte_gpa;
        if (s2tlb_hit) begin
          // Stage-2 TLB命中：跳过STAGE2_WALK
          guest_pte_hpa = s2tlb_hpa;
          next_state = READ_GUEST_PTE;
        end else begin
          // Stage-2 TLB未命中：进入完整EPT遍历
          next_state = STAGE2_WALK;
        end
      end

      STAGE2_WALK: begin
        // 逐级遍历EPT (类似非虚拟化PTW)
        mem_req = 1'b1;
        // mem_addr = 根据s2_level和guest_pte_gpa计算
        if (mem_ack) begin
          if (s2_level == 3'd3) begin  // EPT遍历完成
            guest_pte_hpa = mem_data[51:12];
            next_state = READ_GUEST_PTE;
          end else begin
            s2_level <= s2_level + 1;
          end
        end
      end

      READ_GUEST_PTE: begin
        mem_req  = 1'b1;
        mem_addr = {guest_pte_hpa, guest_pte_gpa[11:0]};
        if (mem_ack) begin
          if (guest_level == 3'd3) begin
            // 最后一级: 翻译目标数据页的GPA
            next_state = COMPLETE;
          end else begin
            guest_level <= guest_level + 1;
            // 从PTE中提取下一级Guest页表的GPA
            guest_pte_gpa <= mem_data[51:12];
            next_state = S2_QUERY;  // 需要翻译新的GPA
          end
        end
      end

      COMPLETE: begin
        fill_valid = 1'b1;
        next_state = IDLE;
      end
    endcase
  end
endmodule

这段代码清晰地展示了嵌套遍历的核心控制流：GUEST_WALK每前进一级（从PML4到PT），都需要通过S2_QUERY $\to$ STAGE2_WALK（或直接命中Stage-2 TLB）来翻译当前Guest PTE的GPA。Stage-2 TLB命中时，整个STAGE2_WALK被跳过，将每一步从 $4+1=5$ 次内存访问降低到 $0+1=1$ 次。在真实的RTL实现中，还需要处理大页检测（Guest或EPT级别的PS位）、A/D位更新、EPT Violation异常路径、以及与PWC的交互，但核心的嵌套状态机模式与上述代码一致。

IOMMU

前两节讨论的地址翻译机制针对的是处理器核心发起的内存访问。然而，在现代计算系统中，I/O设备（如网卡、GPU、NVMe SSD）也会通过DMA（Direct Memory Access）直接读写系统内存。在虚拟化环境中，如果I/O设备的DMA操作直接使用Host物理地址，那么Guest OS将无法安全地控制设备——一个恶意或有bug的Guest驱动程序可能指示设备DMA到任意物理地址，破坏其他VM或Hypervisor的内存。

IOMMU（I/O Memory Management Unit）正是为了解决这一问题而引入的硬件机制。IOMMU位于I/O总线（如PCIe）和内存控制器之间，对所有来自I/O设备的DMA请求进行地址翻译和权限检查，确保设备只能访问被授权的物理内存区域。

IOMMU的DMA地址翻译在概念上与第 9.0 章讨论的Cache一致性协议有着深刻的联系——两者都需要确保多个观察者看到一致的内存视图。在Cache一致性中，多个CPU核心通过Snoop/Directory协议看到一致的Cache行内容；在IOMMU中，CPU和I/O设备通过DMA Remapping看到一致的内存映射。当CPU修改了一段内存的映射（例如将一个页面从VM A迁移到VM B），不仅需要刷新CPU的TLB（通过TLB Shootdown），还需要刷新IOMMU的IOTLB和设备端的ATC——否则设备可能使用过时的映射DMA到已被重新分配的内存，导致数据损坏。这种"多层失效"的需求使得虚拟化环境下的地址翻译一致性管理比非虚拟化环境复杂得多。

Intel VT-d

Intel的VT-d（Virtualization Technology for Directed I/O）是x86平台上最广泛部署的IOMMU技术。VT-d最早在2006年的3000系列芯片组中引入，现已成为Intel平台的标准功能。

DMA Remapping

VT-d的核心功能是DMA Remapping（DMA地址重映射）。每个I/O设备的DMA请求携带一个PCIe的Requester ID（包含Bus:Device:Function三元组，简称BDF），VT-d根据Requester ID查找对应的页表，将设备使用的DMA地址翻译为Host物理地址。

VT-d使用两级表结构来管理DMA翻译：

（1）Root Table。根表由256个Root Entry组成（每个对应一个PCIe Bus编号），每个Root Entry指向一个Context Table。

（2）Context Table。上下文表由256个Context Entry组成（每个对应Bus上的一个Device:Function组合），每个Context Entry指向一个Second-Level Page Table（SLPT），并包含该设备的DMA翻译配置（如地址宽度、Domain ID等）。

（3）Second-Level Page Table。DMA翻译使用的页表，结构与EPT类似，采用4级基数树。将设备的DMA地址翻译为Host物理地址。

Scalable Mode

从Intel Cascade Lake开始，VT-d引入了Scalable Mode（可扩展模式），用一种更灵活的Scalable Mode Root Table和Scalable Mode Context Entry替代了传统的Root/Context Table结构。Scalable Mode的主要改进包括：

PASID支持。每个设备可以拥有多个PASID（Process Address Space Identifier），每个PASID对应一个独立的页表。这使得同一个设备可以同时为多个进程提供隔离的DMA地址空间——例如，一个SR-IOV网卡可以为不同的虚拟功能分配不同的PASID和页表。
First-Level翻译。Scalable Mode支持类似CPU的First-Level（Guest VA $\to$ GPA）和Second-Level（GPA $\to$ HPA）两级翻译，使IOMMU可以直接使用CPU的页表进行DMA翻译，实现真正的共享虚拟内存（Shared Virtual Memory, SVM）。设备可以直接使用进程的虚拟地址发起DMA，IOMMU自动翻译为物理地址，无需驱动程序手动进行pin和DMA映射。
嵌套翻译。在虚拟化环境中，Scalable Mode支持First-Level和Second-Level的嵌套翻译，使得Guest中的设备驱动可以直接使用Guest虚拟地址进行DMA操作。

Domain隔离

VT-d使用Domain的概念来管理设备的内存隔离。一个Domain代表一个隔离的DMA地址空间，通常对应一个VM。属于同一Domain的所有设备共享同一份Second-Level Page Table，具有相同的DMA地址映射。Domain通过Domain ID（16位）标识，VT-d的IOTLB条目使用Domain ID进行标记，类似于CPU TLB中的ASID。

这种Domain-based隔离使得：

不同VM的设备使用不同的DMA地址空间，无法互相访问对方的内存。
同一VM的多个设备可以共享DMA地址空间，简化了内存管理。
Hypervisor可以通过按Domain失效IOTLB条目来高效地处理页表更新，而无需全局刷新。

VT-d的IOTLB设计

VT-d内部的IOTLB用于缓存DMA地址翻译结果，其设计与CPU的L2 sTLB类似但有以下关键差异：

标签结构：IOTLB条目的标签包含Source ID（BDF，16位）+ PASID（20位，Scalable Mode下）+ Domain ID（16位）+ 虚拟页号（VPN，最多40位），总比较宽度可达92位——远超CPU TLB的48–64位。
失效机制：VT-d通过MMIO寄存器接口执行IOTLB失效操作。软件写入失效描述符（指定失效粒度：全局、按Domain、按页），VT-d硬件扫描IOTLB并失效匹配的条目。这一过程是异步的——软件需要读取状态寄存器来确认失效完成。
页表遍历器：VT-d集成了专用的DMA地址翻译PTW，支持多个并发遍历。与CPU PTW不同，VT-d PTW的遍历路径是Root Table $\to$ Context Table $\to$ SLPT的三段式结构，前两段是设备配置查找而非地址翻译。

VT-d的IOTLB性能直接影响DMA延迟。在网络I/O密集型工作负载中，每个小包（64字节）的DMA可能涉及多个描述符的翻译。如果IOTLB容量不足导致高Miss率，DMA延迟将从IOTLB命中的约20ns增加到包含页表遍历的200–500ns——这对于追求微秒级延迟的RDMA或kernel-bypass网络栈来说是不可接受的。

Posted Interrupts

VT-d从Ivy Bridge开始支持Posted Interrupts，这是一种与VM-Exit密切相关的优化。在传统模式下，设备向Guest VM发送的中断需要触发VM-Exit，由Hypervisor转发给Guest。Posted Interrupts允许硬件直接将设备中断注入到Guest VM中，无需VM-Exit。

Posted Interrupts的实现依赖于一个内存中的Posted Interrupt Descriptor（PID）结构，Hypervisor为每个vCPU分配一个PID。VT-d在处理设备中断时，如果检测到目标vCPU正在运行（处于VMX non-root模式），直接将中断信息写入PID并通知CPU，CPU通过PIR（Posted Interrupt Request）机制注入中断，无需VM-Exit。如果目标vCPU当前未运行，中断被暂存在PID中，等vCPU被调度运行时批量注入。

Posted Interrupts对I/O密集型虚拟化工作负载的性能影响显著：在高PPS（Packets Per Second）的网络I/O场景中，每个数据包可能触发一个中断，传统模式下每个中断都导致VM-Exit（约700周期）。如果PPS达到100万，VM-Exit的开销为 $10^6 \times 700 = 7 \times 10^8$ 周期/秒——在5GHz处理器上占14%的处理能力。Posted Interrupts将这一开销降低到接近零。

中断重映射

除了DMA地址翻译，VT-d还提供中断重映射（Interrupt Remapping）功能。中断重映射通过一个Interrupt Remapping Table（IRT）控制设备中断的路由——确保设备的中断只能发送到被授权的CPU和中断向量，防止恶意设备通过伪造中断来攻击系统。IRT由Hypervisor维护，每个表项（IRTE）包含目标CPU的APIC ID、中断向量、触发模式等信息。设备发送的MSI/MSI-X中断经过VT-d的中断重映射引擎时，VT-d使用中断消息中的handle字段索引IRT，将中断重定向到IRTE中指定的目标。

ARM SMMU

ARM的SMMU（System Memory Management Unit）是ARM平台的IOMMU实现。SMMU的最新版本为SMMUv3（定义在ARM System Architecture的SMMU Specification中），广泛部署在ARM服务器和嵌入式SoC中。

Stream Table

SMMUv3使用Stream Table来管理设备的翻译配置。每个I/O设备通过一个StreamID（类似于PCIe的Requester ID）来标识。Stream Table是一个以StreamID为索引的表，每个表项（Stream Table Entry, STE）包含该设备的翻译配置。

Stream Table支持两种组织方式：

线性表（Linear Stream Table）。所有STE连续存放在一个数组中，StreamID直接作为索引。适用于StreamID空间较小的系统。
二级表（2-Level Stream Table）。Stream Table分为两级：第一级表（L1 Stream Table Descriptor）的每项指向一个第二级表的基地址。StreamID的高位索引第一级，低位索引第二级。适用于StreamID空间较大但设备稀疏的系统，避免为未使用的StreamID分配内存。

Context Descriptor

每个STE指向一个或多个Context Descriptor（CD）。Context Descriptor包含地址翻译的具体配置，包括：

TTB0/TTB1：Stage-1翻译表的基地址（类似于CPU的TTBR0/TTBR1）。
ASID：用于TLB标记，区分同一设备的不同地址空间。
翻译配置：地址空间大小、页大小、内存属性等。

当设备支持SubstreamID（类似PASID）时，STE指向一个CD Table，以SubstreamID为索引查找对应的CD。这使得同一设备的不同DMA流可以使用不同的页表和地址空间。

二阶段翻译

SMMUv3支持与CPU类似的二阶段翻译：

Stage-1：设备的I/O虚拟地址（IOVA） $\to$ 中间物理地址（IPA / GPA）。使用CD中指向的Stage-1页表。
Stage-2：IPA $\to$ 物理地址（PA / HPA）。使用STE中指向的Stage-2页表。

在虚拟化环境中，典型的配置是：Stage-1页表由Guest驱动维护（将IOVA翻译为GPA），Stage-2页表由Hypervisor维护（将GPA翻译为HPA，可以与CPU的Stage-2页表共享）。

SMMU TLB与缓存

SMMUv3内部包含TLB和页表遍历缓存，结构与CPU的TLB类似。SMMU的TLB使用StreamID、SubstreamID和VMID作为标记，确保不同设备和VM的翻译条目正确隔离。当Hypervisor修改Stage-2页表时，需要通过SMMU的失效接口（TLBI命令）来失效受影响的TLB条目。

硬件描述 2 — IOTLB的设计细节：与CPU TLB的对比

IOMMU内部的TLB（称为IOTLB）在结构上与CPU的TLB类似，但在设计约束上有显著差异：

容量：IOTLB的容量通常为128–4096项，介于CPU的L1 TLB和L2 sTLB之间。Intel VT-d的IOTLB典型配置为512–2048项，ARM SMMU的IOTLB分为L1（约128项，按StreamID分区）和L2（约4096项，统一存储）。
组织方式：IOTLB通常采用组相联设计（4–16路），而非CPU L1 TLB的全相联。原因是IOTLB的延迟约束不如CPU TLB严格——DMA请求的延迟以百纳秒计，IOTLB的查找延迟（通常10–50ns）在DMA总延迟中占比较小。
标签宽度：IOTLB条目的标签比CPU TLB更宽。除了虚拟页号外，还需要包含设备标识（BDF/StreamID/device_id，通常16–20位）和可选的PASID（通常20位）。标签总宽度可达80–100位，显著高于CPU TLB的48–64位。
并发需求：高端网卡或GPU可能同时产生数十个DMA请求，IOTLB需要支持高吞吐量的查找。某些SMMU实现支持多端口IOTLB或流水线化查找来满足带宽需求。
一致性维护：IOTLB的失效操作通过Command Queue异步执行，与CPU TLB的同步INVLPG不同。这意味着IOTLB的失效存在延迟——在命令被执行之前，DMA可能使用旧映射。软件必须在Command Queue中插入Wait命令来确保失效完成后才释放物理页。

SMMUv3通过Command Queue和Event Queue与软件交互：软件通过Command Queue向SMMU发送翻译失效、配置更新等命令；SMMU通过Event Queue向软件报告Page Fault、配置错误等事件。这种基于队列的接口设计比基于MMIO寄存器的传统方式更高效，适合高吞吐量的DMA翻译场景。

Stall Model与Fault Model

SMMUv3定义了两种DMA翻译故障处理模型。在Stall Model下，当DMA翻译失败时（如Stage-1 Page Fault），SMMU挂起该DMA事务并通过Event Queue通知软件。软件处理完故障（如调入缺失的页面）后，通过Command Queue发送Resume命令，SMMU恢复被挂起的DMA事务。Stall Model是PRI功能的基础——它允许DMA操作在遇到缺页时暂停而非失败。在Fault Model下，SMMU直接中止故障的DMA事务并返回错误，不进行挂起和恢复。Fault Model更简单，适用于不需要按需调页的场景。

案例研究 4 — ARM N2 SoC中的SMMU部署

ARM Neoverse N2平台（用于数据中心服务器）集成了SMMUv3实例来服务PCIe和片上设备的DMA翻译。N2的SMMU配置包括：

2级Stream Table，支持最多 $2^{20}$ 个StreamID。
每设备支持最多 $2^{20}$ 个SubstreamID（PASID）。
Stage-1和Stage-2均支持4KB、16KB和64KB页大小。
SMMU TLB：多级TLB结构，L1 TLB约128项（按StreamID分区），L2 TLB约4096项。
硬件页表遍历器（PTW）：支持多个并发的页表遍历请求，以避免DMA翻译成为I/O性能的瓶颈。
Stage-2页表可与CPU共享，减少内存开销和一致性维护的复杂度。

RISC-V IOMMU

RISC-V IOMMU规范于2023年底完成ratification，定义了一个与RISC-V虚拟化扩展和Sv39/Sv48/Sv57页表格式兼容的IOMMU架构。RISC-V IOMMU的设计吸收了Intel VT-d和ARM SMMU的经验，但在某些方面做了简化。

Device Context

RISC-V IOMMU使用Device Directory Table（DDT）来管理设备的翻译配置。DDT以设备ID（device_id，类似于BDF或StreamID）为索引，每个表项（Device Context, DC）包含该设备的翻译配置。DDT支持1级、2级和3级结构，适应不同规模的系统。

每个Device Context包含以下关键字段：

iohgatp：Stage-2页表的根物理地址和翻译模式，格式类似于CPU的hgatp。
fsc：First-Stage Context，包含Stage-1页表的根地址和翻译模式，格式类似于satp。
GSCID/PSCID：Guest和Process的标识符，用于IOMMU TLB标记（分别类似于VMID和ASID）。
MSI翻译配置：用于MSI（Message Signaled Interrupt）地址的翻译和过滤。

翻译模式

RISC-V IOMMU支持以下翻译模式组合：

仅Stage-2（Bare + Sv39x4/Sv48x4/Sv57x4）：设备DMA地址被视为GPA，直接通过Stage-2翻译为HPA。这是将物理设备直接分配给VM（Device Passthrough）时的典型配置。
仅Stage-1（Sv39/Sv48/Sv57 + Bare）：设备DMA地址被视为IOVA，通过Stage-1翻译为PA。用于非虚拟化环境下的DMA隔离和地址空间管理。
两级翻译（Sv39/Sv48/Sv57 + Sv39x4/Sv48x4/Sv57x4）：Stage-1将IOVA翻译为GPA，Stage-2将GPA翻译为HPA。用于虚拟化环境中Guest直接使用设备的场景。

Process Context（PASID支持）

当设备支持PASID时，RISC-V IOMMU使用Process Directory Table（PDT）来管理每个PASID的翻译配置。PDT以process_id为索引，每个表项（Process Context, PC）包含该PASID的Stage-1页表地址和PSCID。这使得同一设备的不同DMA流可以使用不同的地址空间，支持共享虚拟内存等高级功能。

命令与事件队列

RISC-V IOMMU采用与ARM SMMU类似的命令队列（Command Queue）和事件队列（Fault Queue）接口。软件通过Command Queue向IOMMU发送翻译失效（IOTINVAL）和设备目录更新（IOFENCE）等命令。当DMA翻译失败（如Page Fault）时，IOMMU将故障信息写入Fault Queue，供软件处理。

RISC-V IOMMU的实现考量

与Intel VT-d和ARM SMMU相比，RISC-V IOMMU的设计有几个值得硬件实现者关注的特点：

DDT的灵活级数。DDT支持1级、2级和3级结构，实现者可以根据目标系统的设备数量选择最优级数。对于仅有少量PCIe设备的嵌入式SoC，1级DDT（一个简单的平面表）足够且开销最小；对于有数百个设备的服务器SoC，3级DDT（类似3级页表的树形结构）可以高效地处理稀疏的设备ID空间。
页表格式复用。RISC-V IOMMU的Stage-1和Stage-2页表格式与CPU完全相同（Sv39/Sv48/Sv57），这意味着CPU和IOMMU可以共享同一份Stage-2页表——Hypervisor不需要为IOMMU单独维护一份DMA翻译页表。共享页表不仅节省内存，更重要的是简化了一致性维护——当Hypervisor修改Stage-2页表时，只需要失效CPU的TLB和IOMMU的IOTLB，不需要同步更新两份独立的页表。
WSI（Wait for Supervisor Interrupt）模式。RISC-V IOMMU支持WSI模式，当DMA翻译遇到Page Fault时，IOMMU通过设置一个中断标志位来通知软件，而非写入复杂的Event Queue。WSI模式的实现复杂度低于MSI模式，适合资源受限的嵌入式实现。

HPM：硬件性能监控

RISC-V IOMMU规范还定义了硬件性能计数器接口（Hardware Performance Monitoring, HPM），允许软件监控IOMMU的运行状态，包括翻译请求数量、IOTLB命中率、页表遍历次数、故障事件计数等。这些计数器对于调优虚拟化I/O性能、识别翻译瓶颈至关重要。

MSI翻译

RISC-V IOMMU的一个显著特点是原生支持MSI翻译（MSI Translation）。设备发送的MSI写操作（写入特定的内存地址来触发中断）经过IOMMU时，IOMMU可以将MSI的目标地址翻译为正确的中断控制器地址，并验证中断的合法性。这对虚拟化环境中的中断隔离至关重要——确保设备的中断只能到达被授权的VM和vCPU。

RISC-V IOMMU通过每个Device Context中的MSI Page Table来实现MSI翻译。MSI Page Table将Guest的MSI地址（通常位于一个特定的MMIO地址范围内）翻译为Host的MSI地址。每个MSI Page Table条目包含目标中断控制器的物理地址、中断向量编号和有效位。当设备发送MSI写操作时，IOMMU检测到目标地址落在MSI地址范围内，使用MSI Page Table进行翻译，将中断路由到正确的APLIC（Advanced Platform-Level Interrupt Controller）或IMSIC（Incoming MSI Controller）。

案例研究 5 — 三大IOMMU架构特性对比

表表 12.5对比了Intel VT-d、ARM SMMU和RISC-V IOMMU的关键特性。

特性	Intel VT-d	ARM SMMUv3	RISC-V IOMMU
设备标识	BDF (Requester ID)	StreamID	device_id
设备表结构	Root + Context Table	Stream Table	Device Directory
PASID支持	Scalable Mode	SubstreamID + CD Table	Process Directory
二阶段翻译	1st-Level + 2nd-Level	Stage-1 + Stage-2	Stage-1 + Stage-2
软件接口	MMIO寄存器	Command/Event Queue	Command/Fault Queue
中断翻译	Interrupt Remapping	配合GIC ITS	MSI Translation
页大小	4KB, 2MB, 1GB	4KB, 16KB, 64KB, 2MB, 1GB	4KB, 2MB, 1GB

ATS与PRI

在传统的IOMMU模型中，所有DMA地址翻译都由IOMMU集中处理。然而，对于高带宽设备（如高速网卡、GPU），IOMMU的翻译吞吐量可能成为瓶颈——每个DMA请求都需要经过IOMMU的TLB查找，如果TLB Miss还需要进行完整的页表遍历。PCIe规范定义了两个协议来缓解这一问题：ATS（Address Translation Service）和PRI（Page Request Interface）。

ATS：设备端翻译缓存

ATS（Address Translation Service）允许PCIe设备主动向IOMMU请求地址翻译，并在设备内部缓存翻译结果。ATS的工作流程如下：

（1）设备通过PCIe的Translation Request消息向IOMMU请求将一个IOVA翻译为HPA。

（2）IOMMU完成翻译后，通过Translation Completion消息将翻译结果（HPA及权限信息）返回给设备。

（3）设备将翻译结果缓存在设备内部的ATC（Address Translation Cache）中。

（4）后续的DMA请求如果在ATC中命中，设备直接使用缓存的HPA发起DMA，PCIe TLP（Transaction Layer Packet）的头部中设置AT（Address Type）字段为"Translated"，表示该DMA请求携带的地址已经是翻译后的HPA。

（5）IOMMU收到标记为"Translated"的DMA请求时，仍然需要验证翻译的有效性（检查翻译是否仍然有效、权限是否正确），但可以跳过页表遍历，直接在IOTLB中查找验证。

ATS的核心优势在于将翻译缓存分布到各个设备中，减轻了IOMMU的翻译压力。对于高带宽设备（如100GbE网卡、GPU），ATC可以缓存数千条翻译，使得大部分DMA请求无需经过IOMMU的页表遍历。

ATC失效

当IOMMU或操作系统修改了页表映射（例如取消映射、更改权限）时，必须确保设备ATC中的过时翻译被失效。IOMMU通过PCIe的ATC Invalidation Request消息通知设备失效指定的翻译条目。设备收到失效请求后，必须删除ATC中对应的条目，并通过ATC Invalidation Completion消息确认。

ATC失效的延迟和可靠性是一个重要的设计考虑：失效请求通过PCIe总线传输，延迟可能达到数百纳秒；在失效完成之前，设备可能仍然使用旧的翻译发起DMA。IOMMU必须在确认所有相关设备的ATC失效完成后，才能安全地解除页面的固定（unpin）或重新映射。

PRI：设备发起的缺页请求

在传统的DMA模型中，所有DMA缓冲区必须被固定（pinned）在物理内存中——操作系统不能将DMA缓冲区换出到磁盘，否则设备的DMA访问将失败。这限制了DMA可以使用的内存量，并增加了内存管理的复杂度。

PRI（Page Request Interface）协议允许设备在DMA访问遇到缺页（Page Fault）时，通过PCIe消息向操作系统请求将缺失的页面调入物理内存。PRI的工作流程如下：

（1）设备发起DMA请求，IOMMU进行地址翻译时发现目标页面不存在（Page Table中的Present位为0）或不可访问。

（2）IOMMU不是简单地报告翻译失败，而是挂起（stall）该DMA请求，并通过Page Request消息通知设备和软件。

（3）操作系统的缺页处理程序将缺失的页面从磁盘调入物理内存，更新页表，然后通过Page Response消息通知设备翻译已就绪。

（4）设备重新发起之前挂起的DMA请求，IOMMU成功完成翻译。

PRI使得DMA缓冲区可以像普通的进程内存一样被按需调页（demand paging）和换出，极大地简化了DMA内存管理。结合ATS和共享虚拟内存（SVM），设备可以直接使用进程的虚拟地址发起DMA，与CPU共享同一个页表和地址空间——DMA缓冲区不需要额外的映射、固定或缓冲区管理，编程模型与普通的指针访问无异。

ATS在虚拟化嵌套翻译中的优化效果

ATS在虚拟化环境中的价值更加显著。当IOMMU配置为二阶段翻译时，一次IOTLB Miss触发的嵌套页表遍历与CPU的嵌套遍历具有相同的乘法复杂度。如果Device Context配置为Stage-1（Sv48） + Stage-2（Sv48x4），一次完整的嵌套DMA翻译最坏情况下需要 $4 \times 5 + 4 = 24$ 次物理内存访问——与CPU的EPT嵌套遍历相同。

ATS将翻译结果缓存在设备端的ATC中，后续DMA请求直接使用HPA，完全跳过IOMMU的嵌套翻译。对于高频DMA设备（如网卡的每个数据包需要至少2次DMA：读取描述符和写入数据缓冲区），ATS可以将翻译开销从每DMA 500+周期（IOTLB Miss + 嵌套遍历）降低到接近零（ATC命中）。

ATS的另一个虚拟化场景优化是ATC与Guest IOTLB的协同。在SR-IOV（Single Root I/O Virtualization）部署中，一个物理网卡被拆分为多个VF（Virtual Functions），每个VF分配给不同的Guest VM。每个VF有自己的ATC，缓存该VM的IOVA $\to$ HPA映射。当Hypervisor修改某个VM的Stage-2页表（例如VM内存迁移），只需要失效该VM对应VF的ATC条目，不影响其他VM的VF——这比全局IOTLB刷新高效得多。

PRI的实现挑战

PRI的实现面临若干挑战。首先是设备端请求管理——设备在等待Page Response时不能无限期阻塞所有DMA操作，否则可能导致死锁（例如，Page Response本身需要通过同一个PCIe链路传回设备）。支持PRI的设备通常实现一个PRG（Page Request Group）机制，将相关的DMA请求分组管理，允许未受影响的DMA请求继续执行。

其次是延迟不确定性。操作系统的缺页处理涉及磁盘I/O（如从SSD读取换出的页面），延迟可能从数微秒到数毫秒不等。对于延迟敏感的设备（如网卡），这种不确定性可能导致丢包或性能抖动。因此，在实时性要求高的场景中，通常仍然使用传统的固定内存方案。

最后是安全性考虑。恶意设备可能通过大量的PRI请求来消耗操作系统的资源（如物理内存页帧、页表项），形成一种资源耗尽攻击。IOMMU和操作系统需要对每个设备的PRI请求频率和资源消耗进行限制和审计。

性能分析 3 — ATS/PRI对IOMMU性能的影响

在一个配备100GbE SmartNIC的服务器上，不使用ATS时，每个小包（64字节）的DMA都需要经过IOMMU翻译。在小包线速率（约150 Mpps）下，IOMMU每秒需要处理约3亿次翻译请求（考虑到每个包涉及多个DMA描述符），这对IOMMU的IOTLB和页表遍历器提出了极高的吞吐量要求。

启用ATS后，SmartNIC内部的ATC可以缓存常用的翻译（如固定的DMA缓冲区映射），将大部分翻译在设备端完成。在实测中，ATS可以将IOMMU的翻译负载降低80% $\sim$ 95%，显著减少DMA延迟和CPU中断处理开销。

然而，ATS也有额外开销：ATS Translation Request/Completion消息需要占用PCIe带宽；ATC失效需要额外的延迟；设备端的ATC需要芯片面积。对于DMA模式固定（如固定缓冲区的网络I/O）的场景，ATS的收益最大；对于DMA模式频繁变化（如GPU纹理映射）的场景，ATC的命中率可能较低，ATS的收益有限。

设备端IOTLB容量

支持ATS的设备需要在芯片内部实现ATC，其容量直接影响DMA翻译的命中率。典型的ATC容量为：

高端SmartNIC（如NVIDIA ConnectX-7）：数千条ATC条目，支持多种页大小（4KB、2MB、1GB）。
GPU（如NVIDIA H100）：GPU内部的GMMU（Graphics MMU）包含多级TLB，L1 TLB位于每个SM（Streaming Multiprocessor）中，L2 TLB共享。总容量可达数万条。
NVMe SSD控制器：通常ATC容量较小（几百条），因为NVMe的DMA模式相对固定（PRPs/SGLs指向固定的缓冲区）。

ATS/PRI在虚拟化中的应用

ATS和PRI在虚拟化环境中的应用尤为重要。当一个PCIe设备被直接分配给Guest VM（Device Passthrough / SR-IOV）时，Guest驱动直接控制设备的DMA操作。如果设备支持ATS，设备可以向IOMMU请求将Guest的IOVA翻译为HPA，并在设备内部的ATC中缓存。这种模式下，IOMMU需要执行二阶段翻译——先通过Guest的Stage-1页表将IOVA翻译为GPA，再通过Hypervisor的Stage-2页表将GPA翻译为HPA。ATC缓存的最终结果是IOVA到HPA的映射，因此后续相同IOVA的DMA请求可以完全绕过IOMMU的嵌套翻译。

PRI在虚拟化环境中的实现更为复杂。当设备在Guest中使用PRI请求页面时，IOMMU需要将Page Request转发给正确的Guest或Hypervisor进行处理。如果缺页发生在Stage-1层面（Guest页表中没有映射），应由Guest OS处理；如果发生在Stage-2层面（GPA没有映射到HPA），应由Hypervisor处理。IOMMU必须能够区分这两种情况并正确路由Page Request。

GPU虚拟化中的地址转换

GPU是IOMMU最重要的客户之一，也是虚拟化地址转换最具挑战性的场景。现代GPU（如NVIDIA H100、AMD MI300）拥有自己的多级TLB和地址转换硬件（称为GMMU，Graphics MMU），其设计需求与CPU TLB有显著差异：

极高的翻译吞吐量需求。一个GPU SM（Streaming Multiprocessor）可能每周期发出数十条内存请求，每条都需要地址翻译。一块GPU有100+个SM，系统级的翻译请求速率可达每秒数十亿次——远超CPU的翻译需求。
巨大的工作集。GPU的显存（如HBM3）可达80–192GB，加上通过CXL/NVLink访问的Host内存，GPU的地址空间可达TB级。GPU的TLB需要覆盖的地址范围远超CPU。
SIMT执行模型。GPU的SIMT（Single Instruction, Multiple Threads）执行模型意味着一条warp（32线程）的内存指令可能产生32个不同的地址翻译请求。如果这32个地址分散在不同的页面中，将产生32次独立的TLB查找——这称为TLB divergence。
GPU页表格式。NVIDIA的GPU使用自定义的PDE/PTE格式（与CPU不同），AMD的GPU与CPU共享相同的x86-64页表格式。共享页表格式的优势在于CPU和GPU可以使用相同的页表（Unified Memory / Shared Virtual Memory），减少Hypervisor的管理开销。

在虚拟化环境中，GPU的DMA操作需要经过IOMMU的二阶段翻译。GPU的GMMU内部TLB通常缓存的是IOVA $\to$ HPA的最终映射（如果支持ATS），或者IOVA $\to$ GPA的Stage-1映射（IOMMU负责Stage-2）。由于GPU的翻译请求速率极高，IOMMU成为GPU虚拟化的性能瓶颈之一。

NVIDIA的MIG（Multi-Instance GPU）技术通过将一块物理GPU硬件分区为多个独立的GPU实例来实现GPU虚拟化，每个实例有独立的GMMU和地址空间。MIG避免了传统GPU虚拟化（如vGPU时分复用）的频繁上下文切换和TLB刷新，提供了接近裸机的性能。从地址转换的角度，MIG实质上是将GPU的"VMID"概念从软件（vGPU的时分复用需要TLB刷新）推向硬件（每个MIG实例有独立的TLB，无需刷新）——与CPU的VMID优化异曲同工。

设计提示

IOMMU的设计需要考虑与ATS设备的协同优化。IOMMU的IOTLB应当足够大以服务非ATS设备的翻译需求；IOMMU的页表遍历器应当支持足够的并发度以处理ATS Translation Request的突发流量；ATC失效路径应当低延迟，以确保页表更新能够快速传播到所有设备。在虚拟化环境中，IOMMU还需要确保ATC失效与VM迁移、内存热插拔等操作的正确交互——在迁移一个VM时，必须先完成该VM所有设备的ATC失效，然后才能安全地将VM的内存迁移到另一台物理机。

本章讨论了虚拟化环境下地址转换面临的核心挑战及其硬件解决方案。核心内容可以归纳为以下几点：

（1）二阶段地址转换是硬件辅助内存虚拟化的基础。它使得Guest OS和Hypervisor各自维护独立的页表，MMU在硬件层面自动完成GVA $\to$ GPA $\to$ HPA的嵌套翻译，彻底消除了影子页表带来的高昂软件开销。Intel EPT、AMD NPT、ARM Stage-2和RISC-V H扩展是四种主流的硬件实现，它们在页表项格式、特权级模型和控制寄存器等方面各有特色，但核心原理一致。

（2）嵌套页表遍历的开销是二阶段翻译的主要代价。4级Guest $\times$ 4级Stage-2在最坏情况下需要24次物理内存访问，是非虚拟化环境的6倍。通过嵌套TLB、页表遍历缓存（PWC）、VMID标记和大页映射等多层次优化手段，实际的平均翻译开销可以控制在5% $\sim$ 10%以内。处理器设计者需要在TLB容量、PWC级数、并发PTW数量等参数之间寻找平衡点。

（3）VM-Exit/VM-Entry是虚拟化开销的另一个重要来源。通过VPID/VMID机制消除VM-Exit时的TLB刷新、通过减少不必要的VM-Exit（如EPT消除了影子页表引起的VM-Exit）、以及通过硬件加速的VM-Exit/Entry路径（如AMD的VMLOAD/VMSAVE），VM-Exit对性能的影响已经从早期虚拟化的30%以上降低到现代硬件的2–5%。

（4）机密计算（TDX、SEV-SNP、CCA）在地址转换路径上增加了安全检查步骤，是虚拟化地址转换的最新演进方向。安全检查与性能之间的权衡将是2030年代处理器设计的重要议题。

（5）IOMMU将地址翻译的概念从CPU扩展到I/O设备，通过DMA Remapping实现设备级的内存隔离和虚拟化支持。Intel VT-d、ARM SMMU和RISC-V IOMMU各自定义了完整的设备翻译和管理框架。ATS和PRI协议进一步将翻译缓存和缺页处理能力扩展到设备端，支撑了共享虚拟内存等高级功能，使设备DMA的编程模型向CPU靠拢。

虚拟化环境下的TLB管理策略

虚拟化环境下的TLB管理策略比非虚拟化环境复杂得多，因为需要同时考虑Guest页表变更和Stage-2页表变更对TLB的影响。

Guest页表变更的TLB失效

当Guest OS修改其页表时（如进程切换、munmap等），Guest OS会执行相应的TLB失效指令（x86的INVLPG，ARM的TLBI，RISC-V的SFENCE.VMA）。在虚拟化环境中，这些指令的行为取决于架构：

x86 EPT：Guest的INVLPG指令在Guest模式下正常执行，失效TLB中该VPID + Guest PCID + VPN匹配的条目。由于TLB使用Combined设计（缓存GVA $\to$ HPA），INVLPG需要失效包含该GVA映射的条目，而不仅仅是Stage-1的映射。
ARM Stage-2：Guest的TLBI指令在EL1执行时，被拦截到EL2（或通过VHE直接在EL2执行），失效该VMID下匹配的TLB条目。
RISC-V H扩展：Guest VS模式下的SFENCE.VMA被透明地映射为HFENCE.VVMA，失效Stage-1相关的TLB条目。

Stage-2页表变更的TLB失效

当Hypervisor修改Stage-2页表时（如改变GPA $\to$ HPA映射、实施内存气球回收、或执行VM迁移），必须确保所有核心的TLB中缓存的GVA $\to$ HPA映射被正确失效——因为HPA已经改变。

这一操作比Guest的TLB失效更复杂，原因在于：一个Stage-2映射的变更可能影响多个Guest虚拟地址。例如，如果Hypervisor解除了一个2MB的Stage-2映射（一个GPA区域），所有映射到这个GPA区域内的Guest虚拟地址的TLB条目都需要被失效。但在Combined TLB设计中，TLB条目存储的是GVA $\to$ HPA映射，没有直接的方法通过GPA来查找受影响的条目。

解决方案：

全局刷新：最简单但最昂贵——刷新该VMID下所有TLB条目。Intel的INVEPT（Invalidate EPT）指令和ARM的TLBI VMALLS12E1IS指令提供了按VMID全局刷新的能力。
按GPA选择性刷新：某些处理器（如Intel从Broadwell开始）支持按GPA失效TLB条目。硬件在TLB条目中除了存储GVA $\to$ HPA的映射外，还隐式记录了GPA（或GPA的部分位），使得按GPA的选择性失效成为可能。
两步刷新：先通过Guest页表反向查找受影响的GVA，再按GVA逐个失效。这一方法在软件中实现，但需要Hypervisor维护GPA $\to$ GVA的反向映射表，内存和计算开销较大。

vCPU迁移对TLB的影响

当Hypervisor将一个vCPU从物理核心A迁移到物理核心B时（如负载均衡或NUMA优化），核心A的TLB中缓存的该VM的条目对核心B不可用——因为核心B的TLB中没有这些条目。vCPU迁移后，核心B的TLB需要从零开始预热，产生一系列TLB Cold Miss。

这一TLB预热开销可以通过以下方式缓解：

减少vCPU迁移频率：通过CPU亲和性设置（CPU pinning）将vCPU绑定到固定的物理核心，避免调度器在核心间迁移vCPU。
TLB预热提示：Hypervisor在vCPU迁移后，可以主动触发对VM热页面的PTW，预填充TLB。某些Hypervisor（如KVM）在vCPU调度时使用这种"TLB warm-up"策略。
SMT共享TLB：在支持SMT（同步多线程）的处理器上，同一物理核心的两个逻辑核心共享L2 sTLB。如果两个vCPU被调度到同一物理核心的两个SMT线程上，它们可以部分共享TLB内容。

虚拟化地址转换开销的量化总结

综合本章讨论的所有优化手段，我们可以构建一个端到端的虚拟化地址转换开销模型。表表 12.6展示了从最坏情况到充分优化后各阶段对开销的贡献。

优化手段	关闭	开启	开销降低	累积开销
基线（无TLB，无缓存）	24次	–	–	24次/翻译
Combined TLB (命中率98%)	–	是	$-98\%$	0.48次/翻译
Stage-2 Cache (命中率70%)	–	是	$-60\%$	0.19次/翻译
PWC (PML4/PDPT命中)	–	是	$-30\%$	0.13次/翻译
大页 (2MB Stage-2)	–	是	$-40\%$	0.08次/翻译
最终平均开销				$\approx$ 0.08次/翻译

虚拟化地址转换开销的层次化分解

从表中可以看出，充分优化后的虚拟化地址转换开销约为每次翻译0.08次额外内存访问——相当于裸机的4次访存的2%。这解释了为什么在大多数工作负载中，硬件辅助虚拟化的地址转换开销可以控制在5–10%以内。但这一低开销高度依赖于优化手段的全面部署——任何一个优化的缺失（如未启用大页、TLB容量不足、缺少Stage-2 Cache）都可能导致开销急剧增加。

性能分析 4 — 端到端虚拟化IPC分析

将地址转换开销与VM-Exit开销综合考虑，可以得到完整的虚拟化IPC模型：

\text{IPC}_{\text{virt}} = \frac{\text{IPC}_{\text{bare}}}{1 + \Delta\text{CPI}_{\text{TLB}} \times \text{IPC}_{\text{bare}} + f_{\text{exit}} \times C_{\text{exit}} \times \text{IPC}_{\text{bare}}}

其中 $\Delta\text{CPI}_{\text{TLB}}$ 是虚拟化引入的额外TLB相关CPI（相对于裸机）。这个公式的关键洞察是：虚拟化的总开销不是TLB开销和VM-Exit开销的简单相加，而是两者通过CPI/IPC的非线性耦合。当TLB开销增加导致IPC下降时，相同频率的VM-Exit所占用的"指令时间"比例反而降低（因为每条指令已经需要更多周期）——这种耦合效应使得总开销略小于两者的独立之和。

以一个优化良好的配置为例：裸机IPC = 3.0， $\Delta\text{CPI}_{\text{TLB}} = 0.03$ （使用大页、高命中率TLB）， $f_{\text{exit}} = 10^{-5}$ （每10万条指令1次VM-Exit）， $C_{\text{exit}} = 800$ 周期：

\text{IPC}_{\text{virt}} = \frac{3.0}{1 + 0.03 \times 3.0 + 10^{-5} \times 800 \times 3.0} = \frac{3.0}{1 + 0.09 + 0.024} = \frac{3.0}{1.114} = 2.69

IPC下降约10%，这与业界报告的典型虚拟化开销一致。其中TLB开销贡献约8%（ $0.09/1.114$ ），VM-Exit贡献约2%（ $0.024/1.114$ ）。在优化良好的系统中，TLB开销是虚拟化的主要性能瓶颈，而非VM-Exit。

面向2030年代的虚拟化地址转换展望

虚拟化地址转换技术在2030年代面临几个关键的演进方向：

3级以下的浅层Stage-2。ARM已经支持通过VTCR_EL2.T0SZ限制IPA宽度来减少Stage-2的级数。在大多数云VM配置中（内存不超过4TB），40位IPA（3级Stage-2）即可满足需求，将嵌套遍历的最坏情况从 $4 \times 5 + 4 = 24$ 次降低到 $4 \times 4 + 3 = 19$ 次。Intel和RISC-V目前不支持类似的Stage-2级数配置——这是一个潜在的优化点。
硬件辅助的Page Shattering恢复。如前所述，Page Shattering是虚拟化TLB性能的最大威胁之一。未来的处理器可能实现硬件辅助的大页重建——当PTW检测到多个连续的小页映射具有连续的物理帧时，自动在TLB中合并为等效的大页条目（类似于TLB Coalescing，但应用于Stage-2的EPT映射）。这一优化可以在Page Shattering发生后自动恢复TLB Reach，而不需要Hypervisor显式地重建大页映射。
直接赋予设备Stage-2翻译能力。当前的ATS协议要求设备向IOMMU请求翻译，IOMMU完成Stage-1 + Stage-2的嵌套翻译后返回HPA。未来，智能设备（如DPU/SmartNIC）可能在设备内部直接实现Stage-2翻译——设备内嵌一个小型Stage-2 TLB和PTW，直接遍历Hypervisor共享的Stage-2页表。这将完全消除设备DMA翻译对IOMMU的依赖，将翻译延迟从IOMMU的100+ns降低到设备内部的10–20ns。CXL 3.0规范中的HDM-DB（Host-managed Device Memory - Dynamic Base）功能已经暗示了这个方向。
嵌套虚拟化的硬件加速。嵌套虚拟化（Nested Virtualization）——在一个VM内再运行Hypervisor和VM——需要三阶段地址转换（L1 Guest VA $\to$ L1 Guest PA $\to$ L0 Guest PA $\to$ Host PA），最坏情况的嵌套遍历从 $4 \times 5 + 4 = 24$ 次增加到 $4 \times (4 \times 5 + 4) + 4 \times 5 + 4 = 4 \times 24 + 24 = 120$ 次物理内存访问。这一天文数字的遍历开销使得嵌套虚拟化的性能极差——目前主要通过"影子EPT"等软件方案来避免三阶段硬件遍历。Intel在最新的处理器中开始支持EPT Shadow VMFUNC等硬件加速机制来降低嵌套虚拟化的开销。
机密计算的性能优化。TDX/SEV-SNP/CCA在每次TLB Miss的嵌套遍历中增加的安全检查（RMP查询、GPT检查等）目前约增加10–20%的遍历延迟。未来的处理器可能通过更大的安全检查缓存（如RMP Cache从当前的约256项增加到2048项以上）来减少安全检查的Cache Miss率，将机密计算的地址转换开销降低到与非机密虚拟化接近。

前向桥接。 本章揭示了虚拟化环境下地址转换的核心矛盾：二阶段翻译带来的乘法复杂度使得TLB Miss的代价从裸机的4次访存放大到24次。这一巨大的代价不仅影响正常的Load/Store指令延迟，还会深刻影响处理器的投机执行效率——在第 13.0 章中我们将讨论的存储器一致性模型中，推测性Load需要在最终提交时验证地址翻译的正确性，虚拟化环境下更长的翻译延迟意味着推测窗口必须更大，对ROB容量提出了更高要求。此外，嵌套页表遍历的24次内存访问本身也是24次Cache访问——它们与正常的数据访问竞争Cache带宽和容量，可能导致更多的Cache Miss。这种地址翻译开销与处理器性能的深层耦合，是设计面向云计算时代的高性能处理器必须系统性思考的问题。

虚拟化与地址转换 ​

二阶段地址转换 ​

虚拟化的需求 ​

GVA到GPA到HPA的翻译 ​

Intel EPT ​

EPT的启用 ​

EPT页表结构 ​

EPT Violation与EPT Misconfiguration ​

EPT Accessed和Dirty位 ​

EPT的性能影响与优化 ​

5级EPT ​

AMD NPT ​

NPT的启用 ​

NPT与EPT的差异 ​

NPT的性能 ​

ARM Stage-2翻译 ​

特权级模型 ​

VTTBR_EL2 ​

Stage-2页表格式 ​

ARM Stage-2与Intel EPT的关键差异 ​

Secure Stage-2翻译 ​

VHE：虚拟化宿主扩展 ​

RISC-V H扩展 ​

特权模式 ​

hgatp CSR ​

两级VS/HS CSR ​

HLV/HSV指令 ​

HFENCE指令 ​

RISC-V虚拟化的设计哲学 ​

嵌套页表遍历的开销 ​

二维页表遍历 ​

最坏情况分析 ​

逐步分析 ​

一般化公式 ​

嵌套遍历中的访问局部性分析 ​

5级页表对虚拟化的影响 ​

大页对嵌套遍历的优化 ​

Page Shattering：大页的逆过程 ​

嵌套TLB ​

TLB中缓存GVA到HPA的映射 ​

GPA到HPA的缓存 ​

页表遍历缓存 ​

VMID与TLB效率 ​

VMID的作用 ​

VMID的宽度 ​

VMID回收与TLB失效 ​

TLB分区策略 ​

大页如何缓解容量稀释 ​

Combined TLB vs Split TLB的硬件设计 ​

Combined TLB ​

Split TLB ​

混合方案：Combined + 辅助Stage-2 Cache ​

虚拟化环境下TLB容量稀释的定量分析 ​

稀释公式 ​

容量稀释对AMAT的影响 ​

VM-Exit/VM-Entry与地址转换 ​

VM-Exit的完整流程 ​

地址转换事件触发的VM-Exit ​

VPID/VMID如何消除VM-Exit时的TLB刷新 ​

VM-Exit频率与IPC的关系 ​

机密计算与地址转换 ​

PTW嵌套遍历的SystemVerilog实现 ​

IOMMU ​

Intel VT-d ​

DMA Remapping ​

Scalable Mode ​

Domain隔离 ​

VT-d的IOTLB设计 ​

Posted Interrupts ​

中断重映射 ​

ARM SMMU ​

Stream Table ​

Context Descriptor ​

二阶段翻译 ​

SMMU TLB与缓存 ​

Stall Model与Fault Model ​

RISC-V IOMMU ​

Device Context ​

翻译模式 ​

Process Context（PASID支持） ​

虚拟化与地址转换

二阶段地址转换

虚拟化的需求

GVA到GPA到HPA的翻译

Intel EPT

EPT的启用

EPT页表结构

EPT Violation与EPT Misconfiguration

EPT Accessed和Dirty位

EPT的性能影响与优化

5级EPT

AMD NPT

NPT的启用

NPT与EPT的差异

NPT的性能

ARM Stage-2翻译

特权级模型

VTTBR_EL2

Stage-2页表格式

ARM Stage-2与Intel EPT的关键差异

Secure Stage-2翻译

VHE：虚拟化宿主扩展

RISC-V H扩展

特权模式

hgatp CSR

两级VS/HS CSR

HLV/HSV指令

HFENCE指令

RISC-V虚拟化的设计哲学

嵌套页表遍历的开销

二维页表遍历

最坏情况分析

逐步分析

一般化公式

嵌套遍历中的访问局部性分析

5级页表对虚拟化的影响

大页对嵌套遍历的优化

Page Shattering：大页的逆过程

嵌套TLB

TLB中缓存GVA到HPA的映射

GPA到HPA的缓存

页表遍历缓存

VMID与TLB效率

VMID的作用

VMID的宽度

VMID回收与TLB失效

TLB分区策略

大页如何缓解容量稀释

Combined TLB vs Split TLB的硬件设计

Combined TLB

Split TLB

混合方案：Combined + 辅助Stage-2 Cache

虚拟化环境下TLB容量稀释的定量分析

稀释公式

容量稀释对AMAT的影响

VM-Exit/VM-Entry与地址转换

VM-Exit的完整流程

地址转换事件触发的VM-Exit

VPID/VMID如何消除VM-Exit时的TLB刷新

VM-Exit频率与IPC的关系

机密计算与地址转换

PTW嵌套遍历的SystemVerilog实现

IOMMU

Intel VT-d

DMA Remapping

Scalable Mode

Domain隔离

VT-d的IOTLB设计

Posted Interrupts

中断重映射

ARM SMMU

Stream Table

Context Descriptor

二阶段翻译

SMMU TLB与缓存

Stall Model与Fault Model

RISC-V IOMMU

Device Context

翻译模式

Process Context（PASID支持）