虚拟存储器

1961年，曼彻斯特大学的Atlas计算机在人类历史上首次实现了虚拟存储器——程序不再需要关心物理内存的实际容量和地址分配，操作系统和硬件协同创造了一个"内存无限"的幻觉。这是计算机体系结构史上最成功的抽象之一：六十多年后的今天，每一个运行在现代处理器上的程序仍然生活在这个幻觉之中。

从本书的统一视角来看，虚拟存储器是对物理内存的“并行”共享——多个进程同时使用有限的物理内存资源，而地址翻译是实现这种共享的协议。页表遍历本身也体现了“投机”思想：TLB（第 11.0 章）是对页表条目的缓存，TLB命中是一种对“当前地址翻译在近期不会改变”的投机。而2018年Meltdown漏洞的发现，则深刻地揭示了推测执行（第 3.0 章中讨论的导线延迟约束了页表遍历的物理距离）与安全防护之间的根本张力——处理器在权限检查完成之前推测性地使用数据，这种投机虽然提升了性能，却为侧信道攻击打开了大门。KPTI和Retpoline等防御机制（与第 50.0 章和第 51.0 章中讨论的安全主题密切相关）为这些投机失败设置了安全护栏，但也付出了不可忽视的性能代价。

读完本章，你将理解虚拟存储器从概念到硬件实现的完整体系，掌握多级页表、地址翻译流水线和安全防护机制的核心设计原则。

现代处理器运行的每一个用户态程序都生活在一个精心构造的幻觉之中：它认为自己独享了一块连续的、从零地址开始的巨大内存空间，而事实上，这块"内存"的不同部分可能散布在物理DRAM的各个角落，某些部分甚至根本不在DRAM中而是被交换到了磁盘上。这个幻觉的名称是虚拟存储器（Virtual Memory），它是计算机体系结构中最深刻的抽象之一——与Cache透明地弥合处理器与DRAM之间的速度鸿沟类似，虚拟存储器透明地弥合了程序的地址需求与物理内存的有限资源之间的鸿沟。

虚拟存储器的硬件支撑核心是地址转换机制：处理器发出的每一个访存地址（虚拟地址）在到达Cache或DRAM之前，都必须经过硬件的翻译，映射到真实的物理地址。这一翻译过程涉及页表查询、TLB缓存（将在第 11.0 章中详细讨论）、多级页表遍历等复杂的硬件/软件协同机制。在一个4 GHz的现代处理器中，每秒可能执行超过 $10^{10}$ 次访存操作，每一次访存都需要进行地址转换——这意味着地址转换的延迟和吞吐量直接影响处理器的整体性能。

本章从虚拟存储器的基本概念出发，详细阐述页表结构与多级遍历机制，深入分析x86-64、AArch64、RISC-V三大主流ISA的具体翻译方案，讨论页大小的选择对微架构的深远影响，最后分析页表项中的保护位与现代安全防护机制。

虚拟存储器是理解现代处理器微架构的必要前提——后续章节讨论的TLB（第 11.0 章）、VIPT/PIPT Cache设计、访存流水线与Store Buffer等主题都建立在虚拟存储器的概念框架之上。一个处理器架构师必须深刻理解虚拟地址与物理地址在流水线各阶段的转换时机、页表walk与Cache层次的交互、以及保护检查在数据通路中的位置，才能做出正确的微架构设计决策。TLB的微架构设计将在第 11.0 章中单独展开。

虚拟存储器的概念

虚拟地址与物理地址

处理器执行程序时使用两套不同的地址空间：

虚拟地址（Virtual Address, VA）：处理器核心发出的地址，由指令中的操作数经过计算得到。虚拟地址是程序"看到"的地址，其位宽由ISA定义。例如，x86-64的虚拟地址最宽为57位（LA57模式），AArch64为52位（LVA模式），RISC-V Sv57为57位。
物理地址（Physical Address, PA）：实际用于访问DRAM控制器和I/O设备的地址。物理地址的位宽由硬件平台决定，通常小于或等于虚拟地址位宽。例如，Intel Sapphire Rapids支持52位物理地址（ $2^{52}$ 字节 = 4 PB），AMD Zen 4支持48位物理地址（256 TB）。

图图 10.1展示了虚拟地址到物理地址的基本转换关系。每个进程拥有独立的虚拟地址空间，不同进程的相同虚拟地址可以映射到不同的物理地址——这正是虚拟存储器实现进程间地址隔离的基础。

虚拟地址与物理地址的位宽不对称具有重要的微架构含义。当虚拟地址位宽大于物理地址位宽时（这是现代系统的常见情况），意味着虚拟地址空间的"稀疏"程度远高于物理内存——一个进程的48位虚拟地址空间为256 TB，但典型服务器的物理内存只有几百GB到几TB，虚拟地址空间中超过99%的区域是未映射的。

规范地址

x86-64架构引入了规范地址（Canonical Address）的概念来限制虚拟地址的有效范围。在48位虚拟地址模式下，有效的虚拟地址必须满足：第47位到第63位（共17位）全部相同（全0或全1）。这将虚拟地址空间分为两个区域：低半区0x0000_0000_0000_0000到0x0000_7FFF_FFFF_FFFF（用户态），高半区0xFFFF_8000_0000_0000到0xFFFF_FFFF_FFFF_FFFF（内核态），中间的巨大"空洞"是非规范地址，任何对非规范地址的访问都会触发#GP异常。这一设计为未来扩展虚拟地址位宽留下了空间——当从48位扩展到57位时，中间空洞缩小，但已有程序的地址仍然有效。

虚拟存储器的用途

虚拟存储器服务于多个关键目标，每一个都对现代计算系统不可或缺：

进程间地址隔离

每个进程拥有独立的虚拟地址空间，进程A不可能通过构造任何虚拟地址来访问进程B的物理内存——除非操作系统显式地在两个进程的页表中建立到相同物理页帧的映射（共享内存）。这种硬件级别的隔离是操作系统安全模型的基石。在没有虚拟存储器的系统中（如早期的嵌入式系统或某些实时操作系统），一个程序的野指针可能破坏另一个程序甚至操作系统本身的数据，导致整个系统崩溃。

隔离的粒度由页大小决定——最小的可独立保护的内存区域等于一个页。这意味着页大小也决定了内存保护的最小粒度。在4 KB页下，操作系统可以为每4 KB的内存区域设置独立的访问权限；在2 MB大页下，保护粒度扩大到2 MB。对于需要细粒度内存保护的安全应用（如WebAssembly沙箱），小页提供了更精确的权限控制。

简化编程模型

虚拟存储器使得每个程序都可以假设自己从相同的起始地址（如0x400000）开始加载，使用连续的地址空间进行代码、数据和栈的布局。编译器和链接器不需要知道程序将在哪些物理地址上运行——位置无关代码（PIC）与虚拟存储器的结合使得动态库可以被映射到每个进程虚拟地址空间的不同位置。每个进程的栈可以简单地放在虚拟地址空间的高端，堆从低端向上增长，两者独立扩展而互不影响——这种简洁的内存布局在没有虚拟存储器的系统中几乎不可能实现。

按需分页与过量分配

操作系统可以为进程分配远大于物理内存的虚拟地址空间。当程序调用malloc()分配1 GB内存时，操作系统通常只在页表中建立映射标记（或甚至连页表项都不分配），而不实际分配任何物理页帧。只有当程序真正访问某个虚拟页时，才会触发缺页异常（Page Fault），此时操作系统才分配物理页帧并建立实际的页表映射——这就是按需分页（Demand Paging）。这种"懒惰"策略避免了为不使用的内存浪费物理资源。

Linux的过量分配（Overcommit）策略允许所有进程申请的虚拟内存总和超过物理内存+交换空间的总量。默认情况下（overcommit_memory=0），Linux内核使用启发式方法判断是否允许分配。这一策略使得程序可以"大方地"申请内存而不必精确计算实际使用量——但如果所有进程同时使用了它们申请的全部内存，系统将触发OOM Killer（Out-of-Memory Killer）来强制杀死进程以释放内存。

内存映射文件与共享库

虚拟存储器使得将文件内容映射到进程地址空间成为可能（mmap()系统调用）。程序可以像访问普通内存一样读写文件内容，操作系统和硬件协同处理实际的磁盘I/O——首次读取时触发Page Fault，操作系统从磁盘读入数据；修改后由操作系统在适当时机写回磁盘。多个进程可以将同一个共享库（如libc.so）映射到各自的虚拟地址空间，但它们共享相同的物理页帧——一份libc.so的物理内存副本同时服务于系统中的所有进程。在一个典型的Linux服务器上，libc.so可能被数百个进程共享，但其代码段（约2 MB）只在物理内存中存在一份。

写时复制

写时复制（Copy-on-Write, CoW）是虚拟存储器支持的一种重要优化。当fork()创建子进程时，操作系统不复制父进程的全部物理内存，而是让子进程共享父进程的所有物理页帧，但将这些页标记为只读。当父进程或子进程试图写入某个共享页时，触发缺页异常，操作系统此时才复制该页并为写入方分配新的物理页帧。对于fork()后立即执行exec()的典型场景，CoW避免了大量无意义的内存复制。

CoW的硬件支撑机制完全依赖于页表的权限位——操作系统将CoW页面的PTE标记为只读（R/W=0或W=0），同时在内核的内存管理数据结构中记录该页面的CoW状态和引用计数。当写入操作触发Protection Fault时，内核Page Fault处理程序检查是否为CoW场景（而非真正的权限违例），并执行"复制-分离-更新PTE"的操作序列。这一机制展示了虚拟存储器如何利用硬件异常机制来实现软件层面的内存管理策略。

虚拟化中的嵌套页表

在虚拟化环境中，虚拟存储器增加了额外的复杂度。Guest操作系统维护自己的页表，将Guest虚拟地址（GVA）翻译为Guest物理地址（GPA）。但GPA并非真实的物理地址——Hypervisor通过嵌套页表（Nested Page Table）（Intel称为EPT，AMD称为NPT）将GPA进一步翻译为Host物理地址（HPA）。这种两级翻译是Intel VT-x和AMD-V硬件虚拟化的核心组件之一。

页与页帧

虚拟存储器以页（Page）为基本管理单位。虚拟地址空间被划分为固定大小的虚拟页（Virtual Page），物理内存被划分为相同大小的页帧（Page Frame，也称Physical Page或Physical Frame）。地址转换的本质就是将虚拟页号映射到物理页帧号。

虚拟地址可以被分解为两部分：

\text{VA} = \underbrace{\text{虚拟页号（VPN）}}_{\text{高位}} \;|\; \underbrace{\text{页内偏移（Page Offset）}}_{\text{低位}}

同样，物理地址也可以分解为物理页帧号（PFN）和页内偏移。关键的一点是：页内偏移在虚拟地址和物理地址中完全相同——地址转换只改变高位的页号部分，低位的偏移直接透传。这一特性对TLB和Cache的微架构设计有重要影响（参见第 11.0 章中对VIPT Cache的讨论）。

对于最常见的4 KB页， $p = 12$ 位用于页内偏移（ $2^{12} = 4096$ 字节），其余高位为虚拟页号。以48位虚拟地址、4 KB页为例：

\text{VPN位数} = 48 - 12 = 36 \;\text{位}, \quad \text{虚拟页数} = 2^{36} \approx 687\text{亿}

如果物理地址为52位，则PFN为 $52 - 12 = 40$ 位，最多可寻址 $2^{40} \approx 1.1$ 万亿个物理页帧，对应4 PB的物理内存。

页大小的选择

页大小 $P$ 的选择是体系结构设计中的一个基本决策，它影响着内部碎片、页表大小、TLB覆盖范围等多个方面的权衡。主流的选择包括4 KB（x86-64、RISC-V默认）、16 KB（AArch64的Apple芯片选择）和64 KB（AArch64可选），详细分析见10.4 节。

页帧号的物理意义

物理页帧号（PFN）是物理地址中除去页内偏移之后的高位部分。PFN乘以页大小即得到该页帧在物理内存中的起始字节地址。在Linux内核中，PFN是内存管理的核心索引——struct page数组（mem_map）以PFN为索引，每个struct page（约64字节）描述一个物理页帧的状态（引用计数、页面标志、LRU链表位置等）。对于一台拥有1 TB物理内存的服务器，以4 KB页为单位需要 $2^{28} \approx 2.68$ 亿个struct page，总占用约16 GB——这本身就是一个非平凡的内存开销（约占总物理内存的1.6%）。16 KB页将struct page数组缩小4倍至约4 GB。

地址转换

单级页表

最直接的地址转换机制是单级页表（Single-level Page Table）：在内存中维护一个数组，以虚拟页号（VPN）作为索引，每个数组元素是一个页表项（Page Table Entry, PTE），记录该虚拟页对应的物理页帧号以及各种控制位。

地址转换的过程如下：

从虚拟地址中提取VPN和页内偏移。
以页表基址寄存器（x86-64中为CR3，AArch64中为TTBR0_EL1/TTBR1_EL1，RISC-V中为satp）中的值作为页表的起始物理地址。
用VPN作为索引，访问页表中第VPN项： $\text{PTE地址} = \text{PageTableBase} + \text{VPN} \times \text{PTE\_Size}$ 。
从PTE中读取物理页帧号PFN，与页内偏移拼接得到完整的物理地址。
同时检查PTE中的控制位（有效位、权限位等），若检查不通过则触发Page Fault或保护异常。

单级页表的致命缺陷——内存开销

单级页表的根本问题在于其空间消耗。以48位虚拟地址、4 KB页、8字节PTE为例：

\text{页表大小} = \frac{2^{48}}{2^{12}} \times 8\,\text{B} = 2^{36} \times 8\,\text{B} = 512\,\text{GB}

每个进程需要512 GB的连续物理内存来存储页表——这显然是不可接受的，因为它比大多数系统的全部物理内存还要大。即使使用32位虚拟地址（如x86的传统模式），单级页表也需要 $2^{20} \times 4\,\text{B} = 4\,\text{MB}$ ，对于运行数百个进程的系统来说，总页表内存消耗仍然相当可观。

问题的根源在于：虚拟地址空间是极度稀疏的。一个典型的进程可能只使用了几十MB到几GB的虚拟地址空间，但单级页表必须为整个 $2^{48}$ 字节的虚拟地址空间预留所有表项——绝大多数表项的有效位为0，对应着未映射的虚拟页。多级页表正是为了消除这些无用表项的内存浪费。

值得一提的是，32位系统（如x86的传统分页模式）使用单级页表是可行的： $2^{20}$ 个页表项 $\times 4$ 字节 $= 4\,\text{MB}$ 的页表大小虽然不小，但在物理内存为几GB的系统中是可以承受的。正是从32位到64位的地址空间扩展使得单级页表变得完全不可行，催生了多级页表成为现代系统的标准设计。

表表 10.1展示了单级页表随虚拟地址位宽增长的空间消耗——这个指数级增长清楚地说明了为什么64位系统必须使用多级页表。

VA位宽	VPN位数	PTE数量	页表大小
32位	20	$2^{20} = 1\,\text{M}$	$2^{20} \times 8 = 8\,\text{MB}$
39位 (Sv39)	27	$2^{27} = 128\,\text{M}$	$2^{27} \times 8 = 1\,\text{GB}$
48位 (Sv48/x86-64)	36	$2^{36} = 64\,\text{G}$	$2^{36} \times 8 = 512\,\text{GB}$
57位 (Sv57/LA57)	45	$2^{45} = 32\,\text{T}$	$2^{45} \times 8 = 256\,\text{TB}$

即使是39位VA（RISC-V Sv39），单级页表也需要1 GB——对于绝大多数嵌入式和桌面系统来说都是不可接受的。多级页表通过“只为使用的区域分配子表”的策略，将一个典型进程的页表消耗从GB级别压缩到KB级别，实现了 $10^5$ 到 $10^6$ 倍的空间节省。

多级页表

多级页表（Multi-level Page Table）的核心思想是：将单级页表的扁平索引分解为多级的层次化索引，只为实际使用的虚拟地址区域分配页表内存。未使用的虚拟地址区域在高层页表中就被标记为无效，不需要分配下层页表的存储空间。

以两级页表为例：将VPN分为两部分——高位作为一级索引（L1 Index），低位作为二级索引（L2 Index）。一级页表（Page Directory）的每一项指向一个二级页表；二级页表的每一项才包含最终的PFN。如果一级页表的某一项标记为无效（表示该区域没有任何映射），则不需要为对应的二级页表分配任何内存。

多级页表的节省效果可以量化。考虑一个使用100 MB内存的进程（约25,600个4 KB页），在48位虚拟地址、两级页表的方案下：

一级页表： $2^{18}$ 项（假设VPN高18位为一级索引），每项8字节，共2 MB。
二级页表：只需为实际映射了虚拟页的那些一级项分配二级页表。25,600个页可能分布在少量（比如50个）的一级区域内，每个二级页表 $2^{18}$ 项 $\times$ 8字节 = 2 MB。50个二级页表共100 MB。

这仍然太大。实践中通过增加页表级数来进一步减小每级页表的大小。

页表级数的最优选择

页表级数的选择是虚拟地址位宽、页大小和PTE大小共同决定的结果。设虚拟地址位宽为 $V$ ，页大小为 $P = 2^p$ 字节，PTE大小为 $E$ 字节，页表级数为 $L$ 。则：

每级页表的条目数为 $N = P / E$ ，需要 $\log_2 N$ 位索引。
总的索引位数为 $V - p$ 位（VPN的位宽），需要均匀分配到 $L$ 级中。
因此 $L = (V - p) / \log_2(P/E)$ 。

以x86-64为例： $V = 48$ ， $p = 12$ ， $E = 8$ 字节， $P/E = 4096/8 = 512$ ， $\log_2 512 = 9$ 。

L = \frac{48 - 12}{9} = \frac{36}{9} = 4

恰好4级，这是完美整除的结果。

以AArch64 16 KB粒度为例： $p = 14$ ， $P/E = 16384/8 = 2048$ ， $\log_2 2048 = 11$ 。

L = \frac{48 - 14}{11} = \frac{34}{11} \approx 3.09

不是整数，因此AArch64在16 KB粒度下的最高级索引位数与其他级不同——第一级只有 $34 - 3 \times 11 = 1$ 位索引（只有2个条目），后三级各11位。这就是为什么AArch64的16 KB粒度可以选择3级或4级页表，取决于TCR_EL1.T0SZ的配置。

以RISC-V Sv39为例： $V = 39$ ， $p = 12$ 。

L = \frac{39 - 12}{9} = \frac{27}{9} = 3

同样完美整除。Sv39比x86-64少一级（3级 vs 4级），page walk更快，但虚拟地址空间更小（512 GB vs 256 TB）。

设计提示

多级页表的级数选择遵循一个核心原则：每级恰好一页帧。这约束了每级的索引位数等于 $\log_2(P/E)$ ，而总级数等于VPN位数除以每级索引位数。当除法不能整除时（如AArch64 16 KB粒度），最高级的索引位数会与其他级不同，导致最高级页表的条目数不是 $P/E$ ——这增加了PTW硬件的复杂度（需要根据级别使用不同的索引范围），但仍然保持每级页表大小不超过一个页帧的约束。

从page walk延迟的角度看，每增加一级页表，TLB缺失的最坏情况延迟就增加一次内存访问的时间。因此，在满足虚拟地址空间需求的前提下，级数越少越好。这也是RISC-V提供Sv39/Sv48/Sv57三种选项的原因——应用只需512 GB VA空间时使用Sv39（3级walk），需要更大空间时再升级到Sv48（4级）或Sv57（5级）。

级数的选择

现代系统普遍使用3 $\sim$ 5级页表。增加级数的好处是每级页表更小（通常恰好一个4 KB页），未使用的地址空间在高层就被截断。代价是每次TLB缺失时需要更多次内存访问来遍历页表（page table walk），延迟更大。以4级页表为例，一次完整的page table walk需要4次串行的内存读取操作——在L1 D-Cache命中的情况下每次约4 $\sim$ 5个周期，共16 $\sim$ 20个周期；在Cache全部缺失的最坏情况下，每次内存访问约100 ns（对应400个周期@4 GHz），总延迟高达1600个周期。这就是TLB的存在如此关键的原因。

多级页表的空间节省分析

以x86-64的四级页表、4 KB页为例，分析一个典型进程的页表内存消耗。假设进程的虚拟地址空间布局如下：代码段16 MB（从0x400000开始）、数据段32 MB、堆128 MB、栈8 MB（位于虚拟地址空间顶部附近），以及内核映射区域。进程实际使用的虚拟地址空间约为184 MB，对应约47,000个4 KB页。

页表级别	每表大小	所需表数	总内存	说明
PML4	4 KB	1	4 KB	每个进程恰好1个
PDPT	4 KB	1 $\sim$ 2	4 $\sim$ 8 KB	用户空间+内核空间
PD	4 KB	2 $\sim$ 4	8 $\sim$ 16 KB	代码+数据+堆+栈分布在少量1 GB区域
PT	4 KB	$\sim$ 92	$\sim$ 368 KB	$\lceil 47000/512 \rceil \approx 92$ 个PT
总计			$\sim$ 400 KB	相比单级页表的512 GB节省了 $10^6$ 倍

即使对于一个使用数GB内存的大型应用，四级页表的总内存开销通常也只有几MB到十几MB——这是完全可接受的。多级页表的空间效率来源于虚拟地址空间的稀疏性：绝大多数PML4和PDPT表项指向无效（不存在的下级页表），因此不需要分配对应的页表内存。

“每级恰好一页”的设计约束

多级页表设计中最精妙之处在于一个看似简单的约束：每级页表的大小恰好等于一个物理页帧。以x86-64的四级页表为例，每级512个8字节PTE，总大小 $512 \times 8 = 4096$ 字节 $= 4\,$ KB $=$ 恰好一个4 KB页帧。这绝非巧合，而是精心设计的结果——让我们推导为什么这个约束如此重要。

设页大小为 $P$ 字节，PTE大小为 $E$ 字节。一级页表中的每个PTE覆盖 $P$ 字节的虚拟地址空间（即一个页帧）。如果要求一级页表本身的大小恰好等于 $P$ 字节，则一级页表的条目数为：

N_{\text{entries}} = \frac{P}{E}

对于 $P = 4096$ 字节、 $E = 8$ 字节， $N_{\text{entries}} = 512$ 。每级索引需要 $\log_2 512 = 9$ 位。

这个约束的意义在于：

页表页可以用标准的页帧分配器管理。操作系统不需要为页表维护特殊的内存分配器——分配一个新的页表页与分配一个普通数据页完全相同，都是从伙伴系统（Buddy System）中申请一个4 KB页帧。
页表页本身可以被交换到磁盘。由于每个页表页恰好是一个标准页帧，操作系统原则上可以将不常用的页表页也换出到磁盘——尽管实际上大多数操作系统将页表页固定在内存中（pinned）。
虚拟地址的位字段划分自然对齐。48位VA中，低12位是页内偏移（ $\log_2 4096 = 12$ ），剩余36位被均匀地分成4组，每组9位（ $36 / 4 = 9$ ），恰好对应512个条目。这种均匀划分使得所有级的页表结构完全相同，简化了Page Table Walker的硬件实现。
PTE中的物理地址自然对齐。由于每级页表的物理基址必须4 KB对齐（起始于页帧边界），PTE中存储的下级页表基址的低12位一定为0，这些位可以被复用来存储控制标志（如Present、R/W、U/S等），不需要额外的存储空间。

如果违反了"每级一页"的约束会怎样？考虑一个假想的设计：每级页表包含1024个PTE（10位索引），每个PTE仍为8字节，则每级页表大小为 $1024 \times 8 = 8192$ 字节 $= 8\,$ KB $= 2$ 个页帧。这意味着分配一个页表需要找到两个连续的物理页帧——这比分配单个页帧要困难得多，尤其在系统运行一段时间后物理内存碎片化严重时。RISC-V的Sv39/Sv48/Sv57保持了相同的约束：每级9位索引 $\times$ 8字节PTE $= 4\,$ KB页表页。

对于AArch64的16 KB粒度，约束同样成立但数值不同：每级 $2^{11} = 2048$ 个PTE（11位索引），每PTE 8字节，每级页表 $2048 \times 8 = 16384$ 字节 $= 16\,$ KB $=$ 恰好一个16 KB页帧。Apple的16 KB页并未破坏这一核心设计约束。

页表遍历的地址计算

理解页表遍历的关键在于掌握每一步的地址计算。设当前级页表的物理基址为 $\text{Base}_i$ ，当前级的索引为 $\text{Idx}_i$ ，PTE大小为8字节，则读取当前级PTE的物理地址为：

\text{PTE\_Addr}_i = \text{Base}_i + \text{Idx}_i \times 8

读出的PTE中包含下一级页表的物理基址（PTE中的PPN字段左移12位得到），作为 $\text{Base}_{i+1}$ 。这个过程串行重复4次（对于Sv48或x86-64四级页表），最终从最后一级PTE中提取物理页帧号。

整个遍历过程可以用以下伪代码精确描述：

// 输入：VA（48位虚拟地址），CR3/satp（页表基址）
// 输出：PA（物理地址）或 Page Fault
uint64_t page_table_walk(uint64_t va, uint64_t pt_base) {
    int levels[] = {39, 30, 21, 12};  // 各级索引的起始位
    uint64_t base = pt_base & ~0xFFF; // 对齐到页边界

    for (int level = 0; level < 4; level++) {
        // 提取当前级的9位索引
        int shift = levels[level];
        uint64_t index = (va >> shift) & 0x1FF;  // 0x1FF = 511

        // 计算PTE的物理地址
        uint64_t pte_addr = base + index * 8;

        // 从物理内存读取PTE（这是page walk的延迟来源！）
        uint64_t pte = physical_memory_read(pte_addr);

        // 检查有效位
        if (!(pte & PTE_VALID))
            raise_page_fault(va, FAULT_NOT_PRESENT);

        // 检查是否为大页（中间级叶节点）
        if (is_leaf(pte, level)) {
            // 大页：低位直接从VA中取
            uint64_t ppn = extract_ppn(pte);
            uint64_t offset = va & ((1ULL << shift) - 1);
            return (ppn << shift) | offset;
        }

        // 非叶节点：提取下一级页表的基址
        base = extract_ppn(pte) << 12;
    }
    // 最终级：拼接PPN和页内偏移
    uint64_t ppn = extract_ppn(pte) << 12;
    return ppn | (va & 0xFFF);
}

这段伪代码揭示了page table walk的两个关键性能特征：（1）每级需要一次内存读取（physical_memory_read），4级共4次，且这4次读取是串行的——每次读取的结果（下级基址）是下次读取地址计算的输入；（2）在大页场景下，遍历可以提前终止——2 MB大页只需3次读取，1 GB大页只需2次。

反向页表

除了多级页表之外，还存在另一种地址转换方案——反向页表（Inverted Page Table）。反向页表以物理页帧号为索引（而非虚拟页号），每个条目记录当前占用该物理帧的虚拟页号和进程ID。反向页表的大小与物理内存成正比（而非与虚拟地址空间成正比），因此在物理内存远小于虚拟地址空间时更为紧凑。

然而，反向页表在实际系统中很少使用（IBM Power是少有的例外），原因在于：（1）查找操作需要对虚拟地址进行哈希，然后在哈希冲突链上搜索，延迟不确定且可能很长；（2）不支持多个虚拟地址映射到同一物理帧（共享内存）的自然表达；（3）无法支持按需分页中的"页不在物理内存中"状态——反向页表只记录了当前在物理内存中的映射，被换出到磁盘的页面无法在反向页表中表达。现代处理器几乎全部采用多级正向页表。IBM Power架构是唯一仍在使用哈希页表（Hash Page Table，HPT）变体的主流架构，但从POWER9（2017年）开始也提供了基数树页表（Radix Page Table）选项，与x86-64和AArch64的多级页表结构本质相同。Linux内核在POWER9上默认使用Radix模式。

x86-64的四级与五级页表

x86-64架构是多级页表设计的经典范例。实际上，x86-64页表的设计是由AMD在1999年提出的AMD64规范中首次定义的，Intel随后在2004年以EM64T的名义兼容了这一设计。AMD64定义了四级页表结构，支持48位虚拟地址。Intel在2017年的Ice Lake处理器中引入了五级页表（LA57），将虚拟地址扩展到57位。值得注意的是，尽管四级页表支持的48位虚拟地址空间"仅"256 TB，但在2020年代中期，即使最大的服务器系统的物理内存也不超过几TB——48位VA空间在绝大多数场景下仍然充裕。五级页表主要面向未来的CXL扩展内存和持久化内存（Persistent Memory）场景。

四级页表（48位虚拟地址）

48位虚拟地址按以下方式划分为页表索引：

位域	[47:39]	[38:30]	[29:21]	[20:12]	[11:0]
名称	PML4 索引	PDPT 索引	PD 索引	PT 索引	页内偏移
位数	9	9	9	9	12
项数	512	512	512	512	4096 B

每级页表恰好包含512个8字节的表项，总大小 $512 \times 8 = 4096$ 字节，正好占据一个4 KB物理页帧。这种设计并非巧合——让每级页表的大小等于一个页帧是多级页表设计的核心约束，它使得页表本身可以被操作系统像普通页一样进行管理和分配。

这种"每级一页"的设计还有一个重要的实际好处：页表页可以使用与普通数据页完全相同的分配和释放机制（如Linux的伙伴系统分配器）。操作系统不需要为页表维护特殊的内存分配器——一个新的二级页表就是一个普通的4 KB物理页帧，从伙伴系统中分配出来、清零、然后将其物理地址写入上级页表项的PFN字段即可。当页表不再需要时（如进程退出），将该页帧归还给伙伴系统即可。

图图 10.5展示了x86-64四级页表的完整遍历过程。

CR3寄存器的格式

x86-64的CR3寄存器（也称PDBR，Page Directory Base Register）存储根页表的物理基址和控制信息。当启用PCID时，CR3的格式如下：

位	名称	含义
11:0	PCID	进程上下文标识符（12位），TLB匹配时使用
51:12	PML4/PML5基址	根页表的物理页帧号（40位），乘以4096得到字节地址
62:52	保留	必须为0
63	—	当执行`MOV CR3`时：0=刷新TLB中该PCID的所有非Global条目，1=不刷新（non-invalidating load）

CR3的第63位（仅在MOV CR3指令执行时有效）是PCID功能的关键——当该位为1时，加载新的CR3值不会导致TLB中旧PCID条目的刷新。这使得操作系统可以在进程切换时保留旧进程的TLB条目，显著减少切换后的TLB冷启动代价。

每次MOV CR3操作的硬件行为包括：

更新内部的根页表基址寄存器，后续的page walk将使用新的基址。
更新内部的PCID值，后续的TLB查找将使用新的PCID进行匹配。
如果第63位为0，刷新TLB中所有PCID等于新值的非Global条目（保留G=1的条目和其他PCID的条目）。
如果第63位为1，不执行任何TLB刷新操作。

在Linux内核中，进程切换时的CR3加载通常使用non-invalidating模式（第63位=1），配合per-CPU的PCID分配表来最大化TLB条目的重用率。

x86-64四级页表的遍历步骤

遍历过程的每一步如下：

从CR3寄存器读取PML4的物理基址。CR3的低12位用于标志（如PCID），高位为PML4表的物理页帧号。
用VA[47:39]（9位）索引PML4表，读取PML4E（PML4 Entry）。PML4E包含下一级PDPT表的物理基址。
用VA[38:30]（9位）索引PDPT表，读取PDPTE。若PDPTE的PS（Page Size）位为1，则此处映射一个1 GB的大页，遍历结束。否则PDPTE指向下一级PD表。
用VA[29:21]（9位）索引PD表，读取PDE。若PDE的PS位为1，则此处映射一个2 MB的大页。否则PDE指向下一级PT表。
用VA[20:12]（9位）索引PT表，读取PTE。PTE包含最终的4 KB物理页帧号。
将PTE中的PFN与VA[11:0]拼接得到完整的物理地址。

遍历的具体数值示例

以翻译虚拟地址0x0000_7F40_1234_5678为例（48位VA模式），提取各级索引：

PML4索引：VA[47:39] = 0x0FE = 254
PDPT索引：VA[38:30] = 0x004 = 4
PD索引：VA[29:21] = 0x091 = 145
PT索引：VA[20:12] = 0x045 = 69
页内偏移：VA[11:0] = 0x678 = 1656

假设CR3中的PML4基址为0x1000_0000（物理地址），则：

访问物理地址 $\texttt{0x1000\_0000} + 254 \times 8 = \texttt{0x1000\_07F0}$ ，读取PML4E。
从PML4E提取PDPT基址（假设为0x2000_0000），访问 $\texttt{0x2000\_0000} + 4 \times 8 = \texttt{0x2000\_0020}$ ，读取PDPTE。
从PDPTE提取PD基址（假设为0x3000_0000），访问 $\texttt{0x3000\_0000} + 145 \times 8 = \texttt{0x3000\_0488}$ ，读取PDE。
从PDE提取PT基址（假设为0x4000_0000），访问 $\texttt{0x4000\_0000} + 69 \times 8 = \texttt{0x4000\_0228}$ ，读取PTE。
从PTE提取PFN（假设为0x0005_6789），最终物理地址 $= \texttt{0x0005\_6789} \times 4096 + 1656 = \texttt{0x5\_6789\_0678}$ 。

整个过程涉及4次串行的内存读取操作。如果所有页表项都在L1 D-Cache中命中（约4周期/次），总延迟约为16周期；如果全部缺失到DRAM，总延迟可达数百纳秒。

PTE的格式

x86-64的PTE为64位（8字节），其各位域定义如下：

位	名称	含义
0	Present (P)	有效位。0表示该页不在物理内存中，访问将触发#PF
1	Read/Write (R/W)	0=只读，1=可读写
2	User/Supervisor (U/S)	0=仅Supervisor（Ring 0），1=User可访问
3	Page Write-Through (PWT)	Cache写策略控制
4	Page Cache Disable (PCD)	禁用Cache
5	Accessed (A)	硬件自动设置，表示该页被访问过
6	Dirty (D)	硬件自动设置，表示该页被写入过
7	PS / PAT	页大小（PDE/PDPTE中）或Page Attribute Table索引
8	Global (G)	全局页，上下文切换时不刷新TLB中的该项
11:9	AVL	操作系统可用位
51:12	PFN	物理页帧号（40位，支持52位物理地址）
58:52	保留	必须为0
62:59	MPK	内存保护密钥（Memory Protection Key）
63	NX / XD	No-Execute / Execute-Disable，禁止该页上的代码执行

PTE中Accessed/Dirty位的硬件更新机制

PTE中的A（Accessed）位和D（Dirty）位是操作系统页面置换算法的硬件基础，但它们的硬件更新机制涉及一些微妙的实现细节。

硬件自动设置（x86-64模式）。在x86-64中，当处理器通过page table walk访问一个PTE时，如果PTE的A位为0，处理器会自动将A位设置为1——这意味着page table walker不仅需要读取页表内存，还可能需要写入页表内存。类似地，当处理器首次向某个页面执行Store操作时，如果对应PTE的D位为0，处理器会自动将D位设置为1。

这种硬件自动更新A/D位的机制在微架构层面有以下值得注意的影响：

Page Walk Cache一致性。当PTW将A位从0修改为1时，如果该PTE已经被缓存在L1 D-Cache或Page Walk Cache中，缓存中的副本也必须被更新或无效化。否则后续的page walk可能读到A=0的旧值，导致再次写入A=1，产生不必要的内存写流量。
多核竞争。在多核系统中，两个核心可能同时对同一个PTE执行A位的设置操作（例如两个核心同时首次访问同一个虚拟页）。这需要对PTE的写入操作使用原子的比较-交换（Compare-and-Swap）语义，或者使用总线锁（bus lock）来保证原子性。Intel的实现在设置A/D位时会产生一个隐式的locked read-modify-write操作，这会短暂地锁定相关的Cache行。
TLB与PTE的一致性。一旦A/D位被设置为1并且对应的TLB条目被加载，后续对该页面的访问不再需要修改PTE（因为A/D已经是1）。但当操作系统清除A位（用于页面置换的Clock算法扫描）时，它还需要刷新所有核心TLB中对应的条目——否则TLB中缓存的A=1会阻止硬件在下次page walk时重新设置A位。这就是为什么操作系统的A位清除操作通常伴随着TLB Shootdown。

软件管理模式（RISC-V可选）。RISC-V规范允许实现选择不在硬件中自动设置A/D位，而是在A=0或D=0时触发Access Fault或Store/AMO Page Fault，由操作系统在Page Fault处理程序中设置这些位。软件管理模式的优点是简化了PTW硬件（不需要写回逻辑和原子操作支持），代价是额外的Page Fault开销。对于嵌入式RISC-V核心，软件A/D管理是合理的选择；对于高性能服务器级RISC-V核心（如SiFive P870），通常实现硬件自动设置。

RISC-V规范对A/D位定义了一个精确的语义：当PTE.A=0时，任何访问（读/写/取指）该页面的操作要么触发Page Fault，要么由硬件原子地将A设为1。当PTE.D=0时，任何写入该页面的操作要么触发Store Page Fault，要么由硬件原子地将D设为1（同时也将A设为1）。“原子地”在这里意味着：在多核系统中，A/D位的设置不能丢失——即使两个核心同时触发对同一PTE的A/D设置，最终结果必须是A=1（和/或D=1）。

硬件描述 1 — A/D位更新的原子性保证

在硬件层面，A/D位的原子更新通常通过以下机制之一实现：

（1）Cache行级别的原子RMW。PTW在需要设置A/D位时，对包含该PTE的Cache行执行一次原子的Read-Modify-Write操作。这类似于处理器执行LOCK CMPXCHG指令时的行为——先获取该Cache行的独占权限（M状态），执行修改，然后释放。

（2）总线锁。在较老的实现中（如Intel Pentium系列），A/D位更新通过断言总线上的LOCK#信号来保证原子性。这会暂时阻塞其他核心对总线的访问，影响并行性能。

（3）乐观更新。某些实现采用乐观策略——先尝试以普通Store的方式写入A/D=1，如果Cache一致性协议报告了竞争（如其他核心同时在修改同一个PTE），则重试。由于A/D位只会从0变为1（单调递增），即使发生竞争也不会导致正确性问题——最坏情况是多次重复写入相同的值。

大页（Huge Page）的页表实现细节

大页的实现机制是多级页表设计中一个巧妙的特性：通过在中间级页表中将某个PTE标记为叶节点（而非指向下一级页表的指针），可以直接映射一个大的连续物理区域。

以x86-64的2 MB大页为例，其页表遍历在PD（Page Directory）级停止：

CR3 $\to$ 用VA[47:39]索引PML4，读取PML4E $\to$ 获得PDPT基址。
用VA[38:30]索引PDPT，读取PDPTE $\to$ 获得PD基址。
用VA[29:21]索引PD，读取PDE。此时检查PDE的PS（Page Size）位：
- PS=0：PDE指向下一级PT表，继续遍历（4 KB页）。
- PS=1：PDE是一个叶节点，其PPN字段直接给出2 MB物理页帧的基址。VA[20:0]（21位）全部作为页内偏移。遍历结束，跳过了PT级。

对于1 GB大页，遍历在PDPT级停止：PDPTE的PS=1时，VA[29:0]（30位）全部作为页内偏移，只需2次内存访问。

大页PTE（叶节点PDE/PDPTE）的格式与普通PTE略有不同。以x86-64的2 MB大页PDE为例：

位	名称	含义
0	Present	有效位
1	R/W	读/写权限
2	U/S	用户/特权
3	PWT	Cache写策略
4	PCD	禁用Cache
5	Accessed	已访问
6	Dirty	已修改（仅大页叶节点有D位，普通PDE无D位）
7	PS=1	页大小=1，标识这是一个2 MB大页叶节点
8	Global	全局映射
12	PAT	Page Attribute Table位
20:13	保留	必须为0
51:21	PPN	2 MB对齐的物理页帧号（低21位隐含为0）
62:59	MPK	内存保护密钥
63	NX	不可执行

注意PPN字段从第21位开始（而非第12位），因为2 MB大页的物理基址必须2 MB对齐——低21位全部为0。这意味着操作系统在分配2 MB大页时必须找到一块2 MB对齐的连续物理内存，这就是大页分配需要连续物理页帧的根本原因。

设计提示

在RISC-V中，大页的标识方式更加统一：当中间级PTE的R、W、X中至少有一位非零时，该PTE就是一个叶节点（大页映射）。不需要像x86-64那样使用专门的PS位。这种设计简化了PTW硬件——在每一级遍历中，PTW只需检查R|W|X是否为非零来判断是否到达叶节点，无需为不同级别的PTE使用不同的位域解释逻辑。

RISC-V还规定了大页的对齐要求：如果Level $i$ 的PTE是叶节点，则PPN的低 $i \times 9$ 位必须全部为0。例如Sv39的Level 1叶节点（2 MB大页）要求PPN[8:0]=0；Level 2叶节点（1 GB大页）要求PPN[17:0]=0。违反对齐要求的PTE会触发Page Fault。

五级页表（57位虚拟地址）

Intel的LA57扩展在PML4之上增加了一级PML5表，虚拟地址位划分变为 $9 + 9 + 9 + 9 + 9 + 12 = 57$ 位。57位虚拟地址空间为 $2^{57} = 128\,\text{PB}$ ，足以满足大规模内存映射的需求（如持久化内存、CXL设备的大地址空间）。

五级页表的代价是page table walk需要5次串行内存访问（而非4次），在TLB缺失时延迟进一步增加。在实践中，大多数运行Linux的服务器即使启用了LA57，仍然可以选择使用4级页表（通过设置PML5E使其直接指向PML4）来避免额外的遍历开销。Linux内核从5.5版本开始支持五级页表，但需要通过内核参数显式启用。

PCID/ASID机制——地址空间标识符的深入分析

地址空间标识符是虚拟存储器设计中一个关键的优化机制，它从根本上解决了进程切换时TLB效率低下的问题。三大ISA分别使用不同的术语：x86-64称为PCID（Process Context Identifier），AArch64和RISC-V称为ASID（Address Space Identifier），但核心功能完全一致。

没有ASID时的问题

在没有ASID的系统中，TLB中的每个条目只存储VPN $\to$ PPN的映射，不区分这个映射属于哪个进程。当操作系统执行进程切换（context switch）时，新进程的虚拟地址空间与旧进程完全不同——相同的虚拟地址在不同进程中映射到不同的物理地址。因此，操作系统必须在切换CR3/satp的同时刷新整个TLB（TLB Flush），将所有旧条目清除，以防止新进程错误地使用旧进程的地址映射。

TLB全刷新的代价是严重的。假设一个系统的L1 dTLB有64项、L2 sTLB有2048项，每次进程切换后这些条目全部失效。新进程开始执行时，每个访存地址都将触发TLB缺失和page walk，直到工作集中的热页面逐步重新填充TLB。这个“TLB冷启动”（TLB Cold Start）期间的性能损失可能持续数百到数千个周期。

在一个典型的Linux服务器上，调度器可能每1 $\sim$ 10毫秒切换一次进程。在4 GHz处理器上，10 ms对应40,000,000个周期，而TLB冷启动期间约1000 $\sim$ 5000个周期的额外延迟看似不大。但在频繁切换的场景中（如高并发Web服务器，每秒可能切换数千次），TLB刷新的累积开销变得非常显著——据测量，频繁上下文切换可导致5% $\sim$ 15%的整体性能下降，其中大部分来自TLB冷启动。

ASID解决方案

ASID的核心思想是在TLB的每个条目中增加一个地址空间标识符字段，使得不同进程的TLB条目可以共存于同一个TLB中。TLB查找时，不仅需要匹配VPN，还需要同时匹配ASID——只有VPN和ASID都匹配时才算TLB命中。

\text{TLB命中} \iff (\text{TLB.VPN} = \text{查询VPN}) \;\wedge\; (\text{TLB.ASID} = \text{当前ASID})

当进程切换时，操作系统只需更新页表基址寄存器中的ASID字段（以及PPN字段），无需刷新TLB。旧进程的TLB条目仍然保留在TLB中，但由于新进程的ASID不同，旧进程的条目不会被匹配到。如果旧进程很快被切换回来，它的TLB条目可能仍然有效，从而避免了冷启动代价。

ASID位宽的权衡

ASID的位宽决定了TLB中可以同时区分的地址空间数量，也影响着TLB硬件的面积和功耗：

ISA	名称	位宽	可区分的地址空间数
x86-64	PCID	12位	4,096
AArch64	ASID	8或16位	256或65,536
RISC-V	ASID	16位	65,536

ASID位宽的增加对TLB的CAM（Content-Addressable Memory）匹配逻辑有直接影响。在全相联TLB中，每个TLB条目的匹配逻辑需要同时比较VPN和ASID，总的比较位宽为 $\text{VPN位宽} + \text{ASID位宽}$ 。以Sv48（36位VPN）和16位ASID为例，每个TLB条目的CAM匹配宽度为 $36 + 16 = 52$ 位。对于64项的全相联TLB，每次查找需要 $64 \times 52 = 3328$ 个XNOR比较器同时工作，加上64条匹配线的AND逻辑——这是TLB功耗开销的主要来源。

增加ASID位宽从12位到16位会增加 $64 \times 4 = 256$ 个额外的XNOR门，大约增加8%的CAM面积。这看似不大，但在每个时钟周期都可能触发1 $\sim$ 2次TLB查找的高性能处理器中，累积的功耗增加是不可忽略的。

Global位与ASID的交互

PTE中的Global（G）位与ASID有重要的交互关系。当G=1时，TLB条目在匹配时忽略ASID字段——即该条目对所有地址空间都有效。典型的Global页面包括：

内核代码页和内核数据页——所有进程共享相同的内核映射。
共享库的代码页——如libc.so的.text段。

在TLB的硬件实现中，Global位修改了匹配条件：

\text{TLB命中} \iff (\text{TLB.VPN} = \text{查询VPN}) \;\wedge\; (\text{TLB.G} = 1 \;\vee\; \text{TLB.ASID} = \text{当前ASID})

Global条目在上下文切换时不会被刷新（因为它们对新进程同样有效），进一步减少了切换后的TLB冷启动代价。在典型的Linux系统中，内核空间的TLB条目约占总TLB条目的20% $\sim$ 40%，如果这些条目都是Global的，上下文切换后立即可用的TLB条目比例可观。

ASID回卷与TLB批量刷新

当系统中的活跃进程数超过ASID的表示范围（如16位ASID的65536个值全部用完）时，操作系统需要执行ASID回卷（ASID Rollover）：

将ASID分配计数器重置为0（或1）。
执行一次全局TLB刷新——因为旧的ASID值将被新进程复用，旧进程的TLB条目必须被清除以避免错误匹配。
重新开始按需分配ASID给新调度的进程。

在Linux内核中，ASID的管理实现了惰性ASID分配——不是在fork()时就分配ASID，而是在进程首次被调度到某个CPU核心上运行时才分配。这减少了ASID的消耗速度，推迟了ASID回卷的发生。Linux内核在AArch64上的ASID管理代码使用了一个全局的“generation计数器”——当generation发生变化时，所有旧generation的ASID都视为无效，实现了高效的批量刷新。

x86-64的PCID只有12位（4096个值），在运行大量容器和微服务的服务器上可能很快耗尽。Linux内核在x86-64上维护一个per-CPU的PCID分配表（6个条目），采用LRU策略在少量PCID值之间轮换。这种设计权衡了PCID的有限值空间和TLB命中率——即使只有6个PCID，对于最近被调度的几个进程仍然可以保留TLB条目。

VMID——虚拟化环境的双层标识

在虚拟化环境中，地址转换增加了一个额外的层次：Guest虚拟地址（GVA） $\to$ Guest物理地址（GPA） $\to$ Host物理地址（HPA）。TLB中需要存储完整的GVA $\to$ HPA映射，但不同Guest VM中的相同GVA可能映射到不同的HPA。因此，TLB需要一个额外的标识符来区分不同的Guest VM——这就是VMID（Virtual Machine Identifier）。

在支持虚拟化的系统中，TLB的匹配条件变为三元组：

\text{TLB命中} \iff (\text{VPN匹配}) \;\wedge\; (\text{ASID匹配或G=1}) \;\wedge\; (\text{VMID匹配})

AArch64的VMID为8或16位（由VTCR_EL2.VS字段配置）。RISC-V的H扩展（Hypervisor Extension）在hgatp寄存器中定义了VMID字段。x86-64的Intel VT-x通过VPID（Virtual Processor Identifier，16位）实现类似功能。

VMID的引入进一步增加了TLB条目的CAM匹配宽度。以AArch64为例：VPN(36位) + ASID(16位) + VMID(16位) = 68位的匹配宽度。这是虚拟化对处理器微架构设计的一个显著成本。

嵌套页表遍历（2D Page Walk）的延迟分析

虚拟化环境下的Page Table Walk延迟是非虚拟化环境的乘法级别增长。这是因为Guest页表本身的每一级PTE都存储在Guest物理地址（GPA）空间中，而GPA不是真实的物理地址——每次读取Guest PTE都需要先通过Host的Stage 2页表将GPA翻译为HPA。

以AArch64的4级Stage 1 + 4级Stage 2为例，最坏情况下的总内存访问次数为：

\text{总访问次数} = \underbrace{4}_{\text{Guest级数}} \times \underbrace{(1 + 4)}_{\text{每级Guest PTE的GPA$\to$HPA翻译}} + \underbrace{4}_{\text{最终数据的GPA$\to$HPA}} = 4 \times 5 + 4 = 24

这24次内存访问的来源：Guest页表有4级，读取每一级的Guest PTE时，其GPA需要通过4级Stage 2页表翻译为HPA（4次Host walk + 1次实际读取 = 5次访问），再加上最终数据地址的Stage 2翻译（4次）。

24次串行内存访问的延迟是灾难性的。假设每次访问在L1 D-Cache命中（5周期），总延迟 $= 24 \times 5 = 120$ 周期。如果部分访问缺失到DRAM（200周期），总延迟可能达到数千周期。这就是为什么TLB、PWC和Guest TLB（如Intel的VPID-tagged TLB）在虚拟化环境中至关重要——它们将这个巨大的延迟从常见路径中消除。

设计权衡 1 — ASID位宽的面积-性能权衡

ASID位宽是一个典型的面积与性能的权衡：

更宽的ASID（如16位）允许更多进程的TLB条目共存，减少ASID回卷和TLB刷新的频率，对多进程服务器工作负载有利。但增加了TLB CAM匹配逻辑的面积和每次查找的功耗。
更窄的ASID（如8位或12位）减少了CAM面积和功耗，但在运行大量进程/容器的服务器上可能频繁触发ASID回卷。
x86-64选择了12位PCID（4096个值），这对于桌面系统足够，但在大规模服务器上可能不够用——Linux内核通过per-CPU的PCID LRU管理来缓解。AArch64和RISC-V选择了16位ASID（65536个值），对服务器场景更为充裕。

Page Table Walker硬件

现代高性能处理器配备了专用的Page Table Walker（PTW）硬件单元，可以在TLB缺失时自动执行多级页表遍历，而无需软件干预（这与某些旧式RISC处理器的软件TLB重填形成对比）。

硬件PTW vs 软件TLB Refill的历史演进

早期的MIPS R2000/R3000处理器使用软件TLB Refill机制：TLB缺失触发一个特殊的异常（TLB Refill Exception），由操作系统的异常处理程序在软件中遍历页表并手动将结果写入TLB。软件方案的优势是硬件极为简单（不需要PTW状态机），且操作系统可以使用任意的页表格式。但其代价是每次TLB缺失的延迟很高（数十到上百个周期的异常处理开销），并且异常处理程序本身的指令取指也可能触发iTLB缺失，导致嵌套的TLB异常（需要特殊的wired TLB entries来打破递归）。

现代高性能处理器（x86-64、AArch64、RISC-V的商用实现）全部使用硬件PTW。硬件PTW是一个专用的有限状态机（FSM），直接在硬件中执行页表遍历算法，将结果写入TLB。硬件PTW的优势在于：（1）延迟更低——不需要异常处理的流水线清空和上下文切换开销；（2）可以与处理器流水线并行执行——乱序处理器可以在PTW工作期间继续执行不依赖于TLB缺失结果的其他指令；（3）可以实现推测性page walk——在预测到可能的TLB缺失时提前启动walk。

PTW状态机的结构

PTW的核心是一个有限状态机，其状态对应于页表遍历的各个阶段。以Sv48（四级页表）为例，PTW状态机包含以下主要状态：

状态机的每一次“REQ $\to$ WAIT”转换对应一次内存读取请求。PTW向L1 D-Cache（或专用的Page Walk Cache）发出读请求，然后等待数据返回。数据返回后，PTW检查PTE的有效位和叶节点标志，决定是继续遍历下一级还是完成/报错。

并行PTW

现代高性能处理器通常配备多个并行的PTW实例（2 $\sim$ 4个），可以同时处理多个TLB缺失。这对乱序超标量处理器至关重要——在一个典型的6-wide处理器中，每周期可能发出2 $\sim$ 3个Load/Store操作，当工作集超出TLB覆盖范围时，多个独立的访存操作可能同时触发TLB缺失。

处理器	并行PTW数	PWC容量	PTW访问通过的Cache层次
Intel Golden Cove	4	4级 $\times$ 32–64项	L1D $\to$ L2 $\to$ L3
AMD Zen 4	2	3级 $\times$ TBD	L1D $\to$ L2 $\to$ L3
Apple M2 Avalanche	4	多级	L1D $\to$ L2
SiFive P870 (RISC-V)	2	256项统一	L1D $\to$ L2

多个并行PTW的实现需要仲裁逻辑来管理对L1 D-Cache端口的竞争——PTW的内存请求与正常的Load/Store操作共享相同的Cache端口。在大多数实现中，PTW的请求被赋予中等优先级：高于预取（prefetch）但低于需求请求（demand load/store）。当所有PTW实例都在忙碌时，新的TLB缺失请求会被放入TLB缺失等待队列（TLB Miss Queue），等待某个PTW实例空闲后再启动遍历。

Page Walk Cache（PWC）

Page Walk Cache（PWC，也称Paging Structure Cache或Translation Walk Cache）是PTW性能优化的核心组件。PWC缓存页表遍历过程中的中间级PTE——即PML4E、PDPTE和PDE（但不缓存最终的PT级PTE，因为那已经是TLB的工作）。

PWC的工作原理基于一个关键的局部性观察：同一区域的虚拟地址共享高级页表项。例如：

同一个1 GB区域（ $2^{30}$ 字节）内的所有虚拟地址共享相同的PML4E和PDPTE。
同一个2 MB区域（ $2^{21}$ 字节）内的所有虚拟地址共享相同的PML4E、PDPTE和PDE。

这意味着，如果一个程序的访存局部性使得连续的TLB缺失都发生在相近的虚拟地址区域，PWC可以让page walk跳过已缓存的高级页表项，只需要从较低级别开始遍历。

PWC通常组织为多级独立的小型Cache，每级对应一个页表层次：

PML4 Cache：缓存PML4E，以VA[47:39]为索引。由于PML4只有512个条目，且大多数进程只使用其中极少数几个（通常1 $\sim$ 3个），一个4 $\sim$ 8项的全相联PML4 Cache几乎可以做到100%命中。
PDPT Cache：缓存PDPTE，以VA[47:30]为索引。典型容量为16 $\sim$ 32项，可以覆盖16 $\sim$ 32个不同的1 GB区域。
PD Cache：缓存PDE，以VA[47:21]为索引。典型容量为32 $\sim$ 64项，可以覆盖32 $\sim$ 64个不同的2 MB区域。

PWC的命中率对page walk的平均延迟有决定性影响。以下是一个典型的分析：

假设4级page walk中，每级PTE在L1 D-Cache中命中的延迟为 $t_L = 5$ 周期。若PWC全部缺失，需要4次访问，总延迟 $= 4 \times 5 = 20$ 周期。若PD Cache命中（最常见的情况），只需1次访问（PT级），延迟 $= 5$ 周期，节省了75%的遍历开销。

实测数据表明，在典型的桌面和服务器工作负载中，PWC的PML4级几乎100%命中（因为绝大多数进程只使用极少数PML4条目），PDPT级约90 $\sim$ 95%命中，PD级约70 $\sim$ 85%命中。因此，大多数page walk实际上只需要1 $\sim$ 2次内存访问（而非完整的4次），这大大降低了TLB缺失的平均代价。

PTW与Cache的交互

PTW的内存访问通常经过L1 D-Cache（而非绕过），这意味着页表项会被自然地缓存在数据Cache中。这有两个重要的含义：

（1）频繁访问的PTE在Cache中命中。如果一个虚拟地址区域的PTE频繁被page walk访问，这些PTE会驻留在L1/L2 Cache中，后续的walk延迟只有Cache命中延迟（几个周期）而非DRAM延迟（数百周期）。

（2）PTE的Cache占用。page walk产生的Cache填充会占用L1 D-Cache的容量和带宽。在TLB缺失率很高的工作负载中，大量PTE被加载到L1 D-Cache中，可能驱逐有用的数据，导致数据Cache缺失率上升——形成一种间接的性能干扰。这种现象被称为page walk pollution。

一些处理器的PTW可以选择跳过L1 D-Cache直接访问L2 Cache，以避免污染L1。Intel的实现中，PTW的请求被标记为特殊类型，L1 D-Cache的替换策略会给予PTW填入的行更低的驻留优先级。

推测性Page Walk

一些处理器实现了推测性page walk（Speculative Page Walk）：在检测到即将访问一个可能不在TLB中的地址时（例如通过stride prefetcher预测的下一个访存地址），提前启动page walk。这可以将page walk的延迟隐藏在实际访存需求出现之前。

推测性page walk的触发条件包括：

硬件预取器预测的地址。当L1 D-Cache的stride prefetcher生成一个预取请求时，如果该地址不在dTLB中，可以提前启动page walk来填充TLB。
分支预测器预测的取指地址。当分支预测器预测了一个远跳转目标地址时，如果该地址不在iTLB中，可以提前启动page walk。
连续TLB缺失模式检测。如果PTW观察到连续的TLB缺失呈现递增的VPN模式（如顺序遍历一个大数组），可以推测性地预填充下一个可能缺失的TLB条目。

性能分析 1 — Page Table Walk的延迟分析

在一个典型的现代服务器处理器中，page table walk的延迟取决于各级页表在Cache层次中的命中情况以及PWC的命中率：

最好情况：PWC的PD级命中，只需1次L1 D-Cache访问。延迟约4 $\sim$ 5个周期。
典型情况（PWC PD命中）：PD级在PWC中命中，PT级PTE在L1/L2 Cache中命中。延迟约5 $\sim$ 15个周期。
典型情况（PWC全缺失，Cache部分命中）：高层级页表项（PML4、PDPT）在L2/L3中命中，低层级（PD、PT）在L1/L2中命中。总延迟约40 $\sim$ 80个周期。
最坏情况：PWC全缺失，所有4级页表项都需要从DRAM中读取。每级约200 $\sim$ 400个周期（DDR5延迟），总延迟可达800 $\sim$ 1600个周期。

这些数字说明了为什么TLB和PWC对性能至关重要——一个TLB命中只需1 $\sim$ 2个周期，一个PWC命中的TLB缺失约5 $\sim$ 15个周期，而一个完全缺失的page walk可能需要上千个周期。Intel和AMD的现代处理器都配备了专用的page table walker硬件（通常2 $\sim$ 4个并行的walker），同时使用多级TLB（L1 TLB + L2 TLB）和page walk cache来减少walk的平均延迟。

AArch64的翻译方案

AArch64（ARM 64位架构）的地址翻译方案在设计上比x86-64更加灵活，提供了三种不同的翻译粒度（Translation Granule）：4 KB、16 KB和64 KB。不同的粒度决定了页大小、每级索引位数和页表的级数。

两套页表基址

AArch64使用两个页表基址寄存器：

TTBR0_EL1：用于翻译虚拟地址空间的低半部分（用户态地址），即VA的最高位为0的地址。
TTBR1_EL1：用于翻译虚拟地址空间的高半部分（内核态地址），即VA的最高位为1的地址。

这种双页表设计使得用户态和内核态的页表可以完全独立管理。在上下文切换时，只需要更换TTBR0_EL1（切换用户页表），TTBR1_EL1保持不变（所有进程共享内核页表）。相比之下，x86-64只有单一的CR3寄存器，内核页表和用户页表通常共存于同一棵页表树中——这也是KPTI需要为每个进程维护两棵完整页表树的原因之一。

AArch64的双页表设计在安全性方面具有天然优势：在用户态运行时，TTBR1_EL1指向的内核页表不会被翻译逻辑使用（处理器根据VA的最高位选择使用TTBR0还是TTBR1），因此Meltdown类型的攻击在AArch64上更难实施（尽管Cortex-A75曾受到影响，但那是由于微架构的特定推测执行行为而非页表结构问题）。

TTBR0_EL1和TTBR1_EL1都包含一个ASID字段（8位或16位），功能与x86-64的PCID类似——上下文切换时不需要刷新TLB中属于其他进程的条目，只要新进程的ASID不同于旧进程即可。在16位ASID模式下，系统可以同时维护最多65536个不同进程的TLB条目。

TCR_EL1配置

AArch64的翻译行为由翻译控制寄存器（Translation Control Register, TCR_EL1）精细配置，关键字段包括：

T0SZ/T1SZ（各6位）：定义TTBR0/TTBR1管理的虚拟地址空间大小。有效虚拟地址位数 $= 64 - \text{TnSZ}$ 。例如T0SZ=16表示用户态虚拟地址为48位。
TG0/TG1（各2位）：选择翻译粒度（4 KB / 16 KB / 64 KB）。
IPS（3位）：输出物理地址大小（32/36/40/42/44/48/52位）。
SH0/SH1, ORGN0/IRGN0：共享属性和缓存属性配置。

参数	4 KB粒度	16 KB粒度	64 KB粒度
页大小	4 KB	16 KB	64 KB
页内偏移位数	12	14	16
每级索引位数	9	11	13
每级表项数	512	2048	8192
每级页表大小	4 KB	32 KB	64 KB
页表级数	4	4 (或3)	3
大页大小	2 MB / 1 GB	32 MB / 1 GB	512 MB

16 KB粒度的优势

Apple的A系列和M系列处理器选择了16 KB的翻译粒度（macOS和iOS强制使用16 KB页）。这一选择为微架构设计带来了显著优势（详见10.4.3 节），同时也对软件生态产生了影响——所有运行在Apple平台上的应用和库都必须以16 KB对齐编译。

三大ISA页表遍历复杂度的量化对比

表表 10.10定量比较了三大ISA在不同页大小和分页模式下的page walk特性，为处理器设计者提供一个全面的参考框架。

上表中"最坏延迟"假设所有级的PTE都在L1 D-Cache中命中（每级约5周期）。在实际工作负载中，PWC可以将平均walk级数减少1 $\sim$ 2级，使得大多数walk只需1 $\sim$ 2次内存访问。

从表中可以看出几个重要的设计趋势：

AArch64的64 KB粒度最为高效——只需3级walk，且64 KB的大页覆盖范围更广。但64 KB页的内部碎片（平均32 KB浪费）和与软件生态的兼容性限制了其采用范围。
RISC-V Sv39在嵌入式场景中具有延迟优势——只需3级walk，与x86-64/Sv48的4级相比节省25%的walk延迟。
5级页表（x86-64 LA57, RISC-V Sv57）显著增加了walk延迟——多一级意味着额外的5 $\sim$ 400周期延迟。PWC的重要性在5级页表下进一步上升。

AArch64 Stage 2翻译与嵌套页表

AArch64支持两阶段翻译（Stage 1 + Stage 2）用于虚拟化场景。Stage 1将虚拟地址（VA）翻译为中间物理地址（Intermediate Physical Address, IPA）；Stage 2将IPA翻译为最终的物理地址（PA）。Stage 2翻译由Hypervisor（EL2）配置，对Guest OS（EL1）完全透明。

两阶段翻译的硬件实现需要处理一个深层的嵌套问题：Guest OS维护的Stage 1页表本身存储在Guest物理地址空间中，而GPA不是真实的物理地址——PTW在读取Stage 1页表的每一级PTE时，都需要先通过Stage 2页表将GPA翻译为HPA。这导致总的内存访问次数呈乘法关系而非加法关系。

以4级Stage 1 + 4级Stage 2为例，最坏情况的详细分解如下：

读取Stage 1 Level 0 PTE：该PTE的GPA需要经过4级Stage 2 walk才能得到HPA，然后用HPA读取PTE。共 $4 + 1 = 5$ 次内存访问。
读取Stage 1 Level 1 PTE：同理，又需要 $4 + 1 = 5$ 次。
读取Stage 1 Level 2 PTE： $4 + 1 = 5$ 次。
读取Stage 1 Level 3 PTE： $4 + 1 = 5$ 次。
最终数据地址（IPA）需要Stage 2翻译： $4$ 次。

总计 $4 \times 5 + 4 = 24$ 次内存访问。如果Stage 2也使用了大页或PWC命中，实际次数会减少，但最坏情况确实需要24次串行内存访问。

这一巨大开销催生了几种硬件优化：

Combined TLB：TLB直接缓存GVA $\to$ HPA的最终映射（而非GVA $\to$ GPA或GPA $\to$ HPA的中间映射），使得TLB命中时完全不需要执行任何walk。Intel VT-x的EPT和AMD-V的NPT都采用这种方案。
Stage 2 TLB/PWC：为Stage 2的翻译结果单独维护一个缓存。当Stage 1 walk的某级PTE的GPA需要Stage 2翻译时，如果Stage 2 TLB命中，可以跳过Stage 2的walk，大幅减少总访问次数。
VMID标记：TLB中使用VMID标识不同的Guest VM，避免VM切换时刷新TLB。

TLB的CAM硬件结构

虽然TLB的完整微架构设计将在第 11.0 章中详细讨论，但为了理解地址转换的硬件实现，有必要在此介绍TLB的核心硬件结构——内容可寻址存储器（Content-Addressable Memory, CAM）。理解CAM是理解TLB面积、功耗和延迟权衡的基础。

全相联TLB的CAM结构

全相联（Fully Associative）TLB允许任何虚拟页映射存储在TLB的任意条目中，没有索引约束。这种灵活性使得全相联TLB的命中率最高（不存在冲突缺失），但代价是需要将查询的VPN+ASID与所有条目同时比较——这正是CAM的功能。

CAM的基本原理可以类比为一个"反向SRAM"：普通SRAM通过地址输入来读出数据（地址 $\to$ 数据），而CAM通过数据输入来找到匹配的地址/位置（数据 $\to$ 匹配位置）。TLB的CAM接收VPN+ASID作为搜索键，输出匹配条目的位置（如果存在）。

每个TLB条目在CAM中包含以下字段的比较逻辑：

字段	位宽	用途
VPN	36位	虚拟页号（48位VA $-$ 12位偏移）
ASID	16位	地址空间标识符
PPN	44位	物理页帧号（输出）
Flags	$\sim$ 8位	R, W, X, U, G, D, A, 页大小等
总计	$\sim$ 104位	每条目约13字节

CAM匹配逻辑的电路结构

CAM的核心是匹配线（Match Line）电路。每个TLB条目有一条匹配线，用于判断输入的搜索键是否与该条目存储的键值完全匹配。

对于每一位的比较，使用一个XNOR门（同或门）：当输入位与存储位相同时输出1，不同时输出0。然后，将所有位的XNOR输出通过一个大的AND门（与门）汇聚到匹配线上——只有所有位都匹配时，匹配线才输出1。

对于一个64项的全相联TLB，VPN+ASID共52位（36+16），匹配逻辑的规模为：

XNOR比较器数量： $64 \times 52 = 3{,}328$ 个
AND门：64个52输入的AND门（每条匹配线一个）
总比较操作在每次TLB查找时全部并行执行

CAM的功耗分析

CAM的功耗是TLB设计中的关键约束。每次TLB查找时，所有匹配线都会经历一次预充电-评估（Precharge-Evaluate）循环：

预充电阶段：所有匹配线被预充电到高电平（逻辑1）。
评估阶段：输入搜索键，不匹配的位会将对应的匹配线下拉到低电平。只有所有位都匹配的条目，其匹配线才保持高电平。

匹配线的功耗与以下因素成正比：

P_{\text{CAM}} \propto N_{\text{entries}} \times W_{\text{match}} \times C_{\text{ml}} \times V_{\text{dd}}^2 \times f

其中 $N_{\text{entries}}$ 是条目数， $W_{\text{match}}$ 是匹配宽度（位数）， $C_{\text{ml}}$ 是匹配线的单位电容， $V_{\text{dd}}$ 是电源电压， $f$ 是查找频率。

在大多数不匹配的条目中，搜索键与存储值至少有一位不同，匹配线在评估阶段的早期就会被下拉——但预充电的能量已经被消耗。这意味着CAM的功耗几乎不依赖于命中与否——无论是否有条目匹配，所有64条匹配线都要经历完整的预充电-评估周期。

性能分析 2 — TLB CAM功耗的量化估算

以一个在5 nm工艺下实现的64项全相联dTLB为例（52位匹配宽度），假设：

匹配线电容： $C_{\text{ml}} \approx 50\,$ fF（与匹配宽度成正比）
电源电压： $V_{\text{dd}} = 0.75\,$ V
查找频率：每周期1次查找 @ 4 GHz

每次查找的CAM动态功耗：

P_{\text{dynamic}} = 64 \times 50\,\text{fF} \times 0.75^2 \times 4 \times 10^9 \approx 7.2\,\text{mW}

加上SRAM读取PPN和控制位的功耗（约 $3\sim5\,$ mW），一个64项全相联dTLB的总功耗约为 $10\sim12\,$ mW。在一个总核心功耗约5 W的高性能处理器核心中，dTLB约占0.2%——看似不大，但考虑到每个核心可能有4个TLB（iTLB、dTLB、L2 sTLB、以及Page Walk Cache），TLB子系统的总功耗可达核心功耗的1%左右。

组相联TLB——减少比较器数量

为了降低CAM的面积和功耗开销，L2 sTLB通常采用组相联结构。组相联TLB使用VPN的一部分低位作为索引（index）来选择一个组（set），然后只在该组内的几个路（way）中进行CAM匹配。

以一个2048项8路组相联的L2 sTLB为例：

组数： $2048 / 8 = 256$ 组
索引位数： $\log_2 256 = 8$ 位（使用VPN[7:0]或某种哈希）
每次查找只比较8个条目（而非全部2048个）
CAM比较器数量： $8 \times (52 - 8) = 8 \times 44 = 352$ 个（tag部分为52-8=44位）

相比全相联（ $2048 \times 52 = 106{,}496$ 个比较器），组相联将比较器数量减少到 $352/106{,}496 = 0.33\%$ ，功耗降低约 $300\times$ 。代价是可能产生冲突缺失——多个VPN映射到同一个组，当该组的8个路全部被占满时，即使TLB中其他组还有空闲位置，也无法容纳新的映射。

设计提示

现代高性能处理器的TLB通常采用层次化的设计策略：L1 iTLB和L1 dTLB使用全相联结构（48 $\sim$ 128项，1周期延迟），追求最高的命中率和最低的冲突缺失；L2 sTLB使用高路数组相联结构（1024 $\sim$ 4096项，8 $\sim$ 16路，6 $\sim$ 8周期延迟），在容量和功耗之间取得平衡。这种分层设计与Cache层次的设计哲学完全一致：小而快的L1 + 大而慢的L2。TLB的多级层次设计将在第 11.0 章中详细分析。

LVA与LPA扩展

ARMv8.2-LVA（Large Virtual Address）扩展将虚拟地址扩展到52位；ARMv8.2-LPA（Large Physical Address）扩展将物理地址也扩展到52位。52位虚拟地址空间为4 PB。在64 KB粒度下，52位VA使用3级页表；在4 KB和16 KB粒度下仍使用4级页表，但一级页表的有效索引范围增大。

RISC-V的Sv39/Sv48/Sv57

RISC-V架构定义了三种分页模式，分别支持39位、48位和57位的虚拟地址空间：

参数	Sv39	Sv48	Sv57
虚拟地址位数	39	48	57
虚拟地址空间	512 GB	256 TB	128 PB
页表级数	3	4	5
每级索引位数	9	9	9
页大小	4 KB	4 KB	4 KB
大页支持	2 MB / 1 GB	2 MB / 1 GB / 512 GB	2 MB / 1 GB / 512 GB / 256 TB
物理地址位数	56	56	56

satp寄存器

RISC-V的分页模式和页表基址通过satp（Supervisor Address Translation and Protection）寄存器配置。该寄存器的格式为（RV64）：

MODE（位[63:60]，4位）：选择分页模式。0=Bare（无翻译），8=Sv39，9=Sv48，10=Sv57。
ASID（位[59:44]，16位）：地址空间标识符，用于TLB中区分不同进程的翻译条目，避免上下文切换时全部刷新TLB。
PPN（位[43:0]，44位）：根页表的物理页号。根页表的物理地址 $= \text{PPN} \times 4096$ 。

写入satp是RISC-V中改变地址空间的主要操作。与x86-64的CR3不同，RISC-V规范不要求写入satp时自动刷新TLB——软件必须显式执行SFENCE.VMA指令来确保TLB一致性。这种设计给予了软件更大的灵活性：操作系统可以在修改satp后、执行SFENCE.VMA之前，完成其他操作（如更新内核数据结构），从而将TLB刷新的开销与其他操作重叠。

satp的MODE字段还支持一个重要的功能：通过将MODE设为0（Bare），可以完全禁用地址翻译。在Bare模式下，处理器使用的虚拟地址直接作为物理地址使用，不经过任何页表遍历。这对于以下场景很有用：

引导阶段：在操作系统的早期引导代码设置好页表之前，处理器运行在Bare模式下。
简单嵌入式系统：不需要虚拟存储器的嵌入式系统可以始终运行在Bare模式下。
M-mode代码：RISC-V的M-mode（Machine mode）通常运行在Bare模式下，不使用虚拟地址。

从微架构角度看，MODE字段的变化要求PTW硬件支持动态切换遍历级数：Sv39模式下PTW执行3级遍历，Sv48下执行4级，Sv57下执行5级。PTW状态机的最大级数由MODE字段决定——一个同时支持Sv39/Sv48/Sv57的实现需要5级状态机，但在Sv39模式下只执行前3级。

RISC-V PTE格式

RISC-V的PTE为64位（8字节），格式简洁而规整：

位	名称	含义
0	V (Valid)	有效位
1	R (Read)	可读
2	W (Write)	可写
3	X (Execute)	可执行
4	U (User)	用户模式可访问
5	G (Global)	全局映射（对所有地址空间有效）
6	A (Accessed)	已被访问（硬件或软件设置）
7	D (Dirty)	已被写入
9:8	RSW	操作系统保留位
53:10	PPN	物理页号（44位）
60:54	保留	必须为0
62:61	PBMT	页属性（Svpbmt扩展）
63	N	NAPOT位（Svnapot扩展）

RISC-V的PTE权限编码具有一个优雅的特性：当R、W、X三位全为0时，该PTE是一个非叶节点（指向下一级页表的指针）；当R、W、X中至少有一位为1时，该PTE是一个叶节点（直接包含物理页帧映射）。这种区分方式比x86-64使用PS位来区分叶/非叶节点更加统一。

同时，RISC-V规范明确规定了若干非法的RWX组合：W=1但R=0是保留的（不允许只写不读的页面）。这意味着有效的权限组合为：R（只读）、R+W（读写）、X（只执行）、R+X（读+执行）、R+W+X（读+写+执行）——共5种叶节点权限加上R=W=X=0的非叶节点，共6种有效编码。

各位域的硬件使用方式详解

V（Valid，位0）：最基本的有效位。V=0表示该PTE无效，任何使用此PTE的地址转换都将触发Page Fault。PTW在读取每一级PTE时首先检查V位。
R/W/X（位1-3）：权限位，同时编码了叶/非叶节点的区分。PTW利用 $R|W|X$ 的值来判断当前PTE是否是叶节点——如果是，遍历结束；如果不是，继续到下一级。在TLB中，R/W/X位被存储并在每次访存时由MMU检查。
U（User，位4）：控制用户态（U-mode）是否可以访问此页面。当U=1时，U-mode可以访问；当U=0时，只有S-mode（Supervisor）可以访问。S-mode对U=1页面的访问受sstatus.SUM位控制（类似x86-64的SMAP）。
G（Global，位5）：全局映射标志。当G=1时，此映射对所有地址空间有效（TLB匹配时忽略ASID）。上下文切换时不需要刷新G=1的TLB条目。
A（Accessed，位6）：表示此页面自上次清除A位以来被访问过。可由硬件自动设置或触发Access Fault由软件设置。操作系统的页面置换算法（如Clock算法）依赖A位来近似LRU。
D（Dirty，位7）：表示此页面自上次清除D位以来被写入过。只有脏页面在被换出时才需要写回到磁盘/交换区。D位的语义是：如果D=0且发生Store操作，要么硬件原子地将D设为1，要么触发Store/AMO Page Fault由软件设置。
RSW（位8-9）：Reserved for Software，留给操作系统使用的2位。硬件忽略这两位。Linux内核使用RSW位来存储一些页面管理的软件状态。
PPN（位10-53，44位）：物理页号。44位PPN加上12位页内偏移可寻址 $2^{56} = 64\,$ PB的物理地址空间。对于非叶节点PTE，PPN指向下一级页表的物理基址（左移12位得到字节地址）。对于叶节点PTE，PPN是最终物理页帧号。
PBMT（位61-62）：Svpbmt扩展定义的Page-Based Memory Type字段，允许每个页面独立指定内存类型（如Normal Cacheable、IO等），取代了全局的PMA（Physical Memory Attributes）机制。
N（位63）：Svnapot扩展的NAPOT位。当N=1时，PPN的低位用于编码一组连续的自然对齐页面。

Sv39的遍历过程

以Sv39为例，39位虚拟地址的分解为 $9 + 9 + 9 + 12$ 位。遍历过程如下：

从satp.PPN获取根页表（Level 2）的物理基址。
用VA[38:30]索引Level 2页表，读取PTE。若R|W|X不全为0，则为1 GB大页（superpage），遍历结束。
否则用PTE.PPN作为Level 1页表的基址，用VA[29:21]索引，读取PTE。若为叶节点，则为2 MB大页。
否则继续用PTE.PPN作为Level 0页表的基址，用VA[20:12]索引，读取PTE（必须为叶节点），得到4 KB页帧号。
将PFN与VA[11:0]拼接得到56位物理地址。

Sv39遍历的完整数值示例

以翻译RISC-V Sv39模式下的虚拟地址0x00_003F_E012_3ABC为例（39位有效VA），逐步展示遍历过程。

首先提取各级索引和页内偏移：

39位有效VA = 0x7F_E012_3ABC
Level 2索引：VA[38:30] = 0x1FF = 511
Level 1索引：VA[29:21] = 0x009 = 9
Level 0索引：VA[20:12] = 0x123 = 291
页内偏移：VA[11:0] = 0xABC = 2748

假设satp.PPN = 0x0_8000_0（根页表位于物理地址0x8000_0000，即2 GB处）。

第1步：读取Level 2 PTE。

\text{PTE地址} = \texttt{0x8000\_0000} + 511 \times 8 = \texttt{0x8000\_0000} + \texttt{0xFF8} = \texttt{0x8000\_0FF8}

PTW向L1 D-Cache发出对物理地址�0�的读请求。假设返回的PTE值为�1�。解析此PTE：V=1, R=0, W=0, X=0 $\to$ 非叶节点（指向Level 1页表）。PPN = �2� $\to$ Level 1页表物理基址 = $\texttt{0x80\_0000} \times 4096 = \texttt{0x0\_8000\_0000\_0000}$ ... 这里简化为PPN=0x80001，基址=0x8000_1000。

第2步：读取Level 1 PTE。

\text{PTE地址} = \texttt{0x8000\_1000} + 9 \times 8 = \texttt{0x8000\_1048}

假设返回PTE：V=1, R=0, W=0, X=0 $\to$ 非叶节点。PPN指向Level 0页表基址0x8000_2000。

检查是否为2 MB大页：R|W|X = 0，不是叶节点，继续遍历。

第3步：读取Level 0 PTE。

\text{PTE地址} = \texttt{0x8000\_2000} + 291 \times 8 = \texttt{0x8000\_2918}

假设返回PTE = �0�。解析：V=1, R=1, W=1, X=0, U=1, G=0, A=1, D=1。 $R|W|X \neq 0$ $\to$ 叶节点（4 KB页）。PPN = 0x0_0081_0000（简化为0x81000）。

第4步：拼接物理地址。

\text{PA} = \text{PPN} \times 4096 + \text{页内偏移} = \texttt{0x81000} \times \texttt{0x1000} + \texttt{0xABC} = \texttt{0x8\_1000\_0ABC}

整个遍历过程涉及3次串行的内存读取。如果Level 2的PTE在L1 D-Cache中命中（ $\sim$ 5周期），Level 1在L2 Cache中命中（ $\sim$ 15周期），Level 0在L1 D-Cache中命中（ $\sim$ 5周期），总延迟约25周期。如果有PWC缓存了Level 2的PTE，则可以跳过第1步，总延迟降至约20周期。

硬件描述 2 — RISC-V PTW的硬件检查清单

RISC-V规范要求PTW在每一级读取PTE后执行以下检查：

V位检查：若V=0，触发Page Fault（Load/Store/Instruction Page Fault，取决于访问类型）。
保留位检查：若PTE的位[60:54]不全为0，触发Page Fault（保留位非零表示格式错误）。
叶节点判断：若 $R|W|X \neq 0$ ，此PTE是叶节点。
非法RWX组合检查：若W=1且R=0，触发Page Fault（不允许只写不读的页面）。
对齐检查（仅大页）：对于Level $i > 0$ 的叶节点，PPN的低 $9i$ 位必须全为0。例如Level 1叶节点（2 MB大页）要求PPN[8:0]=0。不满足则触发Page Fault。
A位检查：若A=0，要么由硬件原子地将A设为1，要么触发Page Fault由软件处理。
D位检查（仅Store操作）：若D=0，要么由硬件原子地将D（和A）设为1，要么触发Store Page Fault。
权限检查：检查U位（用户态访问权限）、R/W/X位（与访问类型匹配），以及sstatus.SUM和sstatus.MXR标志。

这些检查必须在PTW的状态机中以组合逻辑实现，确保不增加额外的时钟周期延迟。在典型的硬件实现中，所有检查在PTE数据从Cache返回的同一周期内完成。

Svnapot扩展

RISC-V的Svnapot扩展（Naturally Aligned Power-of-2 Pages）提供了一种介于4 KB基础页和2 MB大页之间的中间页大小方案。当PTE的N位（第63位）为1时，PTE.PPN的低位用于编码一组连续的自然对齐页面。例如，Svnapot支持64 KB的NAPOT页（16个连续4 KB页），TLB中只需一个条目即可覆盖64 KB。这种机制特别适合对齐需求不如2 MB大页严格但又希望比4 KB页更大TLB覆盖率的场景。

Svinval扩展

TLB一致性管理是虚拟存储器设计中的重要问题。当操作系统修改了页表项后，需要确保所有核心的TLB中对应的旧条目被清除。RISC-V基础规范使用SFENCE.VMA指令来刷新TLB，但这是一个heavyweight操作（需要等待所有先前的Store操作完成）。Svinval扩展引入了更精细的TLB无效化指令（SINVAL.VMA、SFENCE.W.INVAL、SFENCE.INVAL.IR），允许对多个TLB条目的无效化进行批处理，减少了fence开销。

Sv48与Sv39的PTW差异

从PTW硬件实现的角度看，Sv48和Sv39的差异仅在于遍历的级数不同（4级 vs 3级）。一个同时支持两种模式的PTW实现通常使用一个可配置的最大级数计数器——在Sv39模式下，PTW从Level 2开始（跳过Sv48的Level 3），总共执行3级遍历；在Sv48模式下，从Level 3开始，执行4级遍历。

这种灵活性对RISC-V处理器设计者非常有价值：

嵌入式核心可以只实现Sv39的PTW（3级状态机），节省面积和功耗。
服务器级核心实现完整的Sv48/Sv57 PTW（5级状态机），通过satp.MODE字段在运行时选择分页模式。
Page Walk Cache的设计也需要适配不同的分页模式——在Sv39下PWC只需缓存Level 2和Level 1的PTE（2级），而在Sv48下还需要缓存Level 3的PTE。

RISC-V还有一个独特的PTW行为：当walk过程中遇到一个非叶节点PTE（ $R|W|X = 0$ ）但其PPN的低位不全为0时（对于非叶节点，PPN应该是一个合法的页表页帧号），规范要求触发Page Fault。这是因为非叶节点的PPN直接指向下一级页表的物理基址，如果PPN不合法（如指向I/O地址空间或超出物理内存范围），继续遍历可能导致未定义的硬件行为。PTW必须在每一级对PPN进行合法性检查，增加了组合逻辑的复杂度但保证了安全性。

案例研究 1 — RISC-V page walk的硬件实现——SiFive P870

SiFive的P870核心是截至2025年最高性能的商用RISC-V处理器核心之一，其page table walker实现体现了RISC-V虚拟存储器设计的工业实践。P870支持Sv39和Sv48两种分页模式，配备2个并行的page table walker，使用256项的Page Walk Cache来缓存中间级页表项。

P870的L1 DTLB为64项全相联（4 KB和2 MB页共享），L1 ITLB为48项全相联。L2 TLB为1024项8路组相联，同时服务指令和数据TLB缺失。在Sv39模式下，P870的page walk最多需要3次内存访问；配合Page Walk Cache，平均walk延迟约为15 $\sim$ 30个周期（假设中间级在L1/L2 Cache中命中）。

P870还实现了RISC-V的H扩展（Hypervisor Extension），支持两阶段地址翻译。在虚拟化模式下，Guest的Sv48翻译叠加Host的Sv48翻译，最坏情况下的page walk需要 $4 \times 4 + 4 = 20$ 次内存访问，与AArch64的两阶段翻译开销相当。

设计提示

RISC-V的Sv39（39位VA，512 GB虚拟地址空间）对于大多数嵌入式和桌面应用已经足够。只有在需要大量虚拟地址空间的场景（如大型数据库、持久化内存映射）中才需要Sv48或Sv57。从微架构角度看，Sv39只需3级page walk，比x86-64的4级walk少一次内存访问，TLB缺失延迟更低。RISC-V允许硬件实现选择支持哪些分页模式——一个面向嵌入式的核心可以只支持Sv39，而服务器级核心则应支持Sv48甚至Sv57。

Page Fault的处理

当地址转换过程中遇到无效的页表项（Present/Valid位为0）或权限检查失败时，处理器触发缺页异常（Page Fault）。Page Fault是一种精确异常（Precise Exception）——触发异常时，所有在触发指令之前的指令都已完成，触发指令和之后的指令都未改变体系结构状态。操作系统的Page Fault处理程序负责在软件层面解决问题，然后重新执行触发异常的指令。

Page Fault的常见原因及处理方式如下：

按需分页（Demand Paging）

进程通过mmap()或brk()申请了虚拟地址空间，但操作系统尚未为其分配物理页帧。首次访问时触发Page Fault，操作系统分配物理页帧、将PTE的Present位设为1、填入PFN，然后返回让处理器重新执行该访存指令。

页面换入（Page-in / Swap-in）

该虚拟页之前曾有物理映射，但由于内存压力被操作系统换出（swap out）到磁盘的交换区。PTE中的Present位为0，但操作系统在PTE的剩余位中编码了交换区的位置信息。Page Fault处理程序从磁盘读回数据到新分配的物理页帧，更新PTE后返回。这是延迟最大的Page Fault类型——磁盘I/O需要数毫秒，即使使用NVMe SSD也需要几十微秒，远超处理器的时钟周期时间。

写时复制（Copy-on-Write）

页面存在物理映射且Present位为1，但被标记为只读，而当前操作是写入。如果操作系统判定这是一个CoW页面（如fork()后共享的页面），则分配新的物理页帧、复制原页面内容到新页帧、更新当前进程的PTE指向新页帧并设置为可写、将原页帧的引用计数减1，然后返回。

保护违例（Protection Violation）

访问权限不匹配（如用户态代码试图访问内核页面、试图在NX页面上执行代码、用户态试图写入只读页面且不是CoW场景）。操作系统通常向进程发送SIGSEGV信号（段错误），终止进程。在调试场景中，SIGSEGV信号会生成core dump文件，帮助开发者定位野指针、缓冲区溢出等内存错误。

Instruction Page Fault

除了数据访问的Page Fault外，取指操作同样可能触发Page Fault——当PC（程序计数器）指向一个未映射或不可执行的虚拟页面时，处理器在取指阶段检测到TLB缺失并启动page walk，如果walk结果为无效或NX=1，则触发Instruction Page Fault。这种异常在程序首次执行新代码页（按需分页）或JIT编译器生成的新代码页时经常发生。

Page Fault的性能影响

Page Fault的处理开销极大。即使是最简单的按需分页（不涉及磁盘I/O），一次Minor Page Fault的处理通常也需要数千个时钟周期——包括异常的精确化（清空流水线中的推测指令）、切换到内核态、执行Page Fault处理程序（分配页帧、更新页表、可能需要刷新TLB）、返回用户态并重新执行触发指令。在Linux系统上，一次Minor Page Fault的延迟约为1 $\sim$ 5 s。Major Page Fault（需要从磁盘读取）的延迟则在毫秒量级。

现代操作系统使用多种策略来减少Page Fault的频率和开销：

预取（Prefaulting）：在分配大块内存时，提前为附近的页面也建立映射。
页面预读（Readahead）：当发生Page Fault时，不仅读入目标页面，还读入其后续的若干页面（假设空间局部性）。
大页：使用2 MB或1 GB的大页减少Page Fault次数（一次Page Fault映射更大的区域）。
userfaultfd：Linux的用户态Page Fault处理机制，允许用户态程序自定义Page Fault处理逻辑，用于实现CRIU（进程热迁移）、用户态内存管理等高级功能。

Page Fault与超标量流水线的交互

在超标量乱序处理器中，Page Fault的处理涉及复杂的流水线交互。当一条Load或Store指令在地址翻译阶段检测到TLB缺失时，硬件page table walker开始遍历页表。如果遍历过程中发现PTE无效（触发Page Fault），处理器需要：

将Page Fault标记为该指令的待处理异常（pending exception），暂不立即处理。
继续执行后续指令（推测执行），直到该指令到达ROB（Re-Order Buffer）的提交点。
当该指令成为ROB中最老的指令时，确认异常确实需要处理（之前的指令可能已经修改了页表使得异常不再需要），然后触发精确异常：清空流水线中所有更新的指令，保存精确的异常上下文（PC、异常原因、触发地址），陷入内核态的Page Fault处理程序。
Page Fault处理完成后，操作系统执行iret（x86-64）或eret（AArch64/RISC-V）返回用户态，处理器从触发异常的指令处重新开始执行。

这个过程中有一个微妙但重要的细节：在Load A触发Page Fault之后、到Load A到达ROB头部被精确化之前，后续的指令（Add B、Load C等）已经被推测性地执行了。这些推测执行的结果（寄存器写入、Cache填充等）必须在异常精确化时被完全撤销——这是乱序处理器中ROB和检查点机制的核心功能。

对于Store指令触发的Page Fault，情况稍有不同：Store指令不会在执行阶段就写入内存，而是先将数据放入Store Buffer中，等到提交阶段才真正写出。因此，即使Store指令的地址翻译发现了Page Fault，Store Buffer中的数据不会被写入Cache或内存，回滚时只需丢弃Store Buffer中的条目即可。

A/D位在页面置换中的作用

页面置换算法是操作系统内存管理的核心，而A（Accessed）位和D（Dirty）位是支撑页面置换算法的硬件基础。

操作系统最常用的页面置换策略是Clock算法（也称Second-Chance算法），它是LRU的一种高效近似。Clock算法的工作过程如下：

维护一个“时钟指针”指向物理页帧环形列表的某个位置。
当需要驱逐一个页面时，检查指针当前指向的页帧的A位：
- 如果A=1（最近被访问过）：将A位清除为0，给予该页面“第二次机会”，指针前进到下一个页帧。
- 如果A=0（最近未被访问过）：选择该页面作为驱逐候选。
重复步骤2，直到找到一个A=0的页面。
检查被选中页面的D位：
- 如果D=1（脏页面）：需要先将页面内容写回磁盘/交换区，然后才能重用该页帧。
- 如果D=0（干净页面）：可以直接重用该页帧，无需写回（原始数据仍在磁盘上）。

D位的存在使得操作系统可以区分脏页面和干净页面——驱逐干净页面的代价远低于驱逐脏页面（不需要磁盘写入）。因此，一些改进的Clock算法会优先选择A=0且D=0的页面（最近未访问且干净），其次选择A=0且D=1的页面（最近未访问但脏），从而减少磁盘I/O次数。

从硬件角度看，A位的清除操作（由操作系统的周期性扫描执行）需要配合TLB管理：

操作系统将PTE中的A位从1修改为0（在内存中的页表中直接修改）。
但此时TLB中可能仍然缓存着A=1的旧条目——如果TLB中的A位不被清除，硬件在下次访问该页面时不会重新设置PTE中的A位（因为TLB命中时不会去读PTE）。
因此，操作系统在清除A位后必须执行对应的TLB无效化操作——这会增加下次访问该页面时的TLB缺失代价（需要page walk重新加载PTE）。

这个过程说明了A/D位管理的一个基本权衡：扫描频率 vs. TLB开销。扫描A位太频繁会导致大量TLB无效化，增加TLB缺失率；扫描太不频繁会导致页面置换的精度下降（难以区分"最近1秒内被访问"和"最近10秒内被访问"的页面）。Linux内核通过kswapd守护进程和动态调整的扫描频率来平衡这个权衡。

这一过程的关键约束是精确性——异常触发时的体系结构状态必须与按程序顺序逐条执行的结果完全一致。这要求处理器维护足够的信息来回滚推测执行的所有副作用（包括寄存器写回和存储队列中的待提交写操作）。

案例研究 2 — Linux内核的Page Fault处理路径

在Linux内核（以x86-64为例）中，Page Fault通过IDT（中断描述符表）的第14号向量进入page_fault处理程序。处理器硬件自动将错误码（error code）压栈，编码了异常的原因（P=页面不存在/权限违例、W/R=写/读、U/S=用户/内核、I/D=取指/数据）。内核的处理流程大致为：

从CR2寄存器读取触发异常的虚拟地址（x86-64硬件自动将异常地址写入CR2）。
查找当前进程的VMA（Virtual Memory Area）红黑树，确定该地址是否属于一个合法的内存映射区域。
如果地址不在任何VMA中，发送SIGSEGV信号。
如果地址在合法VMA中，根据VMA的权限标志和错误码判断是按需分配、CoW还是交换区换入。
执行相应的页面分配和页表更新操作。
返回用户态，重新执行触发异常的指令。

在一个4 GHz的Intel处理器上，一次不涉及磁盘I/O的Minor Page Fault的端到端延迟约为2,000 $\sim$ 10,000个时钟周期（0.5 $\sim$ 2.5 s），其中大部分时间花费在内核的VMA查找、页帧分配（可能触发伙伴系统的分裂或合并操作）和页表更新上。

页表在Cache层次中的位置

页表作为内存中的数据结构，自然地参与处理器的Cache层次。理解页表在Cache中的行为对于分析page walk的性能至关重要。

页表项的Cache行为

PTW的每次内存访问都是一次对物理地址的Load操作，这些Load操作经过L1 D-Cache、L2 Cache和L3 Cache的完整Cache层次。频繁被page walk访问的PTE会被Cache自然地缓存。

一个4 KB页表包含512个PTE，占8个64字节的Cache行。以一个典型的进程为例，如果该进程的PML4只有2 $\sim$ 3个有效条目，这些条目分布在1 $\sim$ 2个Cache行中。这意味着PML4级的PTE几乎一定在L1 D-Cache中命中（因为进程运行期间PML4极少变化）。同理，PDPT级的PTE也很可能在L1或L2 Cache中命中。

然而，PT级（最低级）的PTE分布最为分散——映射47,000个页面需要约92个PT表，分布在 $92 \times 8 = 736$ 个Cache行中。如果L1 D-Cache只有512个组（32 KB / 64 B / 8-way），这些PT级PTE可能与正常数据竞争Cache空间，导致频繁的Cache冲突。

Page Walk对Cache的影响

page walk产生的Cache填充有以下影响：

正面影响——自缓存效应。一次page walk将PTE加载到L1/L2 Cache中后，如果短时间内同一区域的其他虚拟地址也发生TLB缺失（这在顺序访问数组时很常见），后续的walk可以直接从Cache中读取PTE，而非从DRAM中获取。PD级PTE的共享特别明显——同一个2 MB区域内的所有4 KB页共享同一个PD条目。
负面影响——Cache污染。page walk将PTE加载到L1 D-Cache中，可能驱逐有用的数据Cache行。在TLB缺失率很高的工作负载中（如随机访问大型数据结构），大量PTE被反复加载到Cache中并驱逐数据，导致数据Cache缺失率上升。这种现象被称为page walk pollution或translation-data Cache interference。
一致性要求。当操作系统修改了某个PTE（如在Page Fault处理中分配新的物理页帧并更新PTE的PFN和权限位），这次Store操作会修改内存中的PTE值。如果该PTE已经被其他核心的Cache缓存，Cache一致性协议会自动无效化旧的副本。PTW在后续的walk中将从更新后的PTE中读取新值。但需要注意的是，TLB中缓存的旧翻译不受Cache一致性协议管理——TLB是一个独立于Cache层次的结构，操作系统必须显式地执行TLB无效化操作来清除旧的TLB条目。

硬件描述 3 — PTW的Cache访问优先级和标记

在多数现代处理器中，PTW的Cache访问被赋予特殊的标记和优先级：

优先级。PTW的请求优先级通常高于硬件预取（prefetch）但低于需求请求（demand load/store）。这确保了PTW不会因为过多的预取请求而被饿死，同时也不会阻塞正常的数据访问。
Cache填充策略。一些处理器将PTW填入的Cache行标记为“低优先级”（low priority），使得这些行在Cache替换时优先被驱逐，减少对数据Cache行的干扰。Intel的某些实现使用RRIP（Re-Reference Interval Prediction）策略，给予PTW填入的行一个较长的重引用间隔预测，使其在LRU近似算法中更容易被替换。
跳过L1D的选项。在极端的Cache pollution场景中，PTW可以被配置为跳过L1 D-Cache直接访问L2 Cache，避免污染对延迟最敏感的L1D。但这增加了PTW的基本延迟（L2延迟 vs L1延迟），是一个功耗-性能的权衡。

地址转换的完整流程

前面几节分别讨论了页表结构、PTE格式、PTW硬件和TLB的CAM结构。本节将这些组件整合在一起，描述一次完整的地址转换从虚拟地址到物理地址的端到端流程。

TLB命中路径——最常见的快速路径

在绝大多数（ $>$ 99%）的访存操作中，地址转换通过TLB命中在1 $\sim$ 2个周期内完成。完整的快速路径流程如下：

处理器核心的Load/Store单元或取指单元生成一个虚拟地址VA。
从VA中提取VPN（高位）和页内偏移（低12/14/16位）。
将VPN和当前ASID发送到L1 dTLB/iTLB的CAM阵列。
CAM同时将VPN+ASID与所有条目并行比较。
如果有一个条目匹配（TLB命中）：
- 从该条目的SRAM部分读出PPN和保护位。
- 将PPN与页内偏移拼接得到物理地址PA。
- 同时检查保护位（R/W/X、U/S等）。若保护检查通过，PA被送入L1 D-Cache/I-Cache进行数据访问。
- 若保护检查失败，标记该指令为Protection Fault（但不立即处理——在乱序处理器中，异常在指令提交时才精确化）。

在VIPT（Virtually Indexed, Physically Tagged）Cache的设计中，Cache的索引操作可以与TLB查找并行进行：

VIPT并行的关键条件是：用于Cache索引的VA位必须全部位于页内偏移范围内（即Cache的每路大小 $\leq$ 页大小）。当此条件满足时，VA的索引位与PA的索引位相同（因为页内偏移在VA和PA中不变），Cache可以在TLB完成翻译之前就开始索引SRAM。TLB产生的PPN随后用于Tag比较，确定哪一路命中。这使得整个TLB查找+Cache访问的总延迟仅为 $\max(\text{TLB延迟}, \text{Cache SRAM延迟}) + \text{Tag比较延迟}$ ，而非两者之和。详细的VIPT流水线设计将在第 11.0 章中分析。

TLB缺失路径——多级TLB查找

当L1 dTLB/iTLB未命中时，请求被转发到L2 sTLB（Shared TLB，同时服务指令和数据的TLB缺失）。L2 sTLB通常为组相联结构，容量更大（1024 $\sim$ 4096项），但访问延迟也更长（6 $\sim$ 8个周期）。

如果L2 sTLB也未命中，则启动硬件Page Table Walk。完整的TLB缺失处理层次如下：

L1 dTLB查找（1 $\sim$ 2周期）：全相联CAM查找。缺失 $\to$
L2 sTLB查找（6 $\sim$ 8周期）：组相联查找。缺失 $\to$
Page Walk Cache查找（1 $\sim$ 2周期）：检查中间级PTE是否已缓存。PWC命中可跳过部分walk级别。
硬件PTW遍历（每级5 $\sim$ 400+周期）：PTW状态机发出内存读请求，经过L1D $\to$ L2 $\to$ L3 $\to$ DRAM的Cache层次。
结果写入TLB：walk完成后，将VPN $\to$ PPN映射写入L1 TLB和L2 sTLB。
重新执行访存：TLB填充完成后，之前因TLB缺失而暂停的Load/Store操作被重新执行，这次将在TLB中命中。

TLB缺失对乱序执行的影响

在乱序超标量处理器中，TLB缺失的处理与流水线有复杂的交互。当一条Load指令触发TLB缺失时，处理器有以下几种处理策略：

策略一：暂停Load但继续其他指令

最常见的策略是将触发TLB缺失的Load指令标记为“等待TLB填充”，同时继续执行不依赖于该Load结果的其他指令。这依赖于乱序处理器的指令窗口（ROB容量）——ROB越大，在等待TLB填充期间可以继续执行的独立指令越多，TLB缺失的延迟被“隐藏”的比例越高。

假设一个256项ROB的处理器在TLB缺失期间可以继续执行约50 $\sim$ 100条独立指令。如果PWC命中时TLB缺失延迟约15周期（在4-wide处理器中约消耗60条指令的执行机会），ROB可以较好地覆盖这个延迟。但如果TLB缺失导致完整的4级page walk且部分PTE缺失到DRAM（延迟约300 $\sim$ 800周期），即使256项的ROB也无法完全隐藏这个延迟——流水线最终会因ROB满而暂停。

策略二：TLB缺失等待队列

现代处理器通常在TLB旁边维护一个TLB缺失等待队列（TLB Miss Queue或TLB Miss Buffer），类似于Cache的MSHR（Miss Status Holding Register）。当多条Load/Store指令同时对同一个虚拟页发生TLB缺失时，只需要启动一次page walk——后续针对同一页面的TLB缺失只需在等待队列中注册，当walk完成时所有等待的指令同时得到满足。

这种TLB缺失合并（TLB Miss Coalescing）对于顺序遍历数组的访存模式尤其有效——连续的Load操作通常访问相邻的地址，这些地址很可能在同一个4 KB页面内，因此只需要一次page walk。

策略三：推测性继续执行

在某些高级实现中，处理器在TLB缺失期间可能推测性地使用上一次的翻译结果来继续执行。例如，如果连续的访存地址在同一个虚拟页内，处理器可以推测当前访问也在同一页面，使用上一次TLB命中的PPN来计算物理地址并发出Cache请求。当TLB walk完成并确认推测正确时，这些操作的结果有效；如果推测错误（实际上是不同的映射），则需要回滚并重新执行。

性能分析 3 — TLB缺失率对IPC的影响——量化分析

TLB缺失对处理器IPC的影响可以用以下模型估算。设：

$r_{\text{mem}}$ ：每条指令的平均访存次数（包括Load和Store），典型值0.2 $\sim$ 0.4
$r_{\text{L1miss}}$ ：L1 dTLB缺失率，典型值0.5% $\sim$ 5%
$r_{\text{L2miss}}$ ：L2 sTLB缺失率（在L1缺失中的比例），典型值5% $\sim$ 30%
$t_{\text{L2TLB}}$ ：L2 sTLB的访问延迟，约6 $\sim$ 8周期
$t_{\text{PTW}}$ ：完整page walk的平均延迟，约30 $\sim$ 200周期

则TLB导致的每指令额外延迟（CPI penalty）为：

\text{CPI}_{\text{TLB}} = r_{\text{mem}} \times r_{\text{L1miss}} \times \bigl( t_{\text{L2TLB}} + r_{\text{L2miss}} \times t_{\text{PTW}} \bigr)

Case 1：SPEC CPU整数（规律访存）。 $r_{\text{mem}}=0.30$ ， $r_{\text{L1miss}}=1\%$ ， $r_{\text{L2miss}}=10\%$ ， $t_{\text{L2TLB}}=7$ ， $t_{\text{PTW}}=50$ ：

\text{CPI}_{\text{TLB}} = 0.30 \times 0.01 \times (7 + 0.10 \times 50) = 0.30 \times 0.01 \times 12 = 0.036

对于基础IPC=3.0的处理器，有效IPC降为 $1/(1/3.0 + 0.036) = 2.72$ ，下降约9%。

Case 2：大内存数据库（随机访问，4 KB页）。 $r_{\text{mem}}=0.35$ ， $r_{\text{L1miss}}=5\%$ ， $r_{\text{L2miss}}=25\%$ ， $t_{\text{PTW}}=150$ ：

\text{CPI}_{\text{TLB}} = 0.35 \times 0.05 \times (7 + 0.25 \times 150) = 0.0175 \times 44.5 = 0.779

有效IPC降为 $1/(1/3.0 + 0.779) = 0.93$ ，下降69%。TLB缺失成为主要性能瓶颈。

Case 3：同一数据库使用2 MB大页。TLB覆盖范围增大512倍， $r_{\text{L1miss}}$ 降至约0.1%， $r_{\text{L2miss}}$ 降至约5%：

\text{CPI}_{\text{TLB}} = 0.35 \times 0.001 \times (7 + 0.05 \times 100) = 0.00035 \times 12 = 0.004

有效IPC为 $1/(1/3.0 + 0.004) = 2.96$ ，几乎无影响。这就是为什么数据库厂商强烈推荐使用大页。

TLB一致性与TLB Shootdown

当操作系统修改了一个进程的页表映射后（例如在munmap()或CoW时），已经在TLB中缓存的旧映射必须被清除。在单核系统中，这只需要执行一条TLB无效化指令（如x86-64的INVLPG、AArch64的TLBI、RISC-V的SFENCE.VMA）即可。但在多核系统中，其他核心的TLB中可能也缓存了同一映射——操作系统需要通知所有相关核心刷新这些条目。这个过程被称为TLB Shootdown。

TLB Shootdown的典型实现步骤：

CPU A修改了某个PTE（在内存中）。
CPU A向所有可能缓存了该PTE的其他CPU发送处理器间中断（IPI, Inter-Processor Interrupt）。
每个收到IPI的CPU暂停当前执行，执行TLB无效化操作（INVLPG或类似指令）。
每个CPU完成TLB无效化后，向CPU A发送确认。
CPU A等待收到所有确认后，才能继续（确保所有核心的TLB都已更新）。

TLB Shootdown的性能开销包括：（1）IPI的发送和接收延迟（通常数百纳秒到几微秒）；（2）被中断CPU的流水线冲刷和恢复开销；（3）CPU A等待所有确认的同步开销。在一个64核系统上，一次TLB Shootdown可能需要中断63个核心，总开销可达数十微秒——对于频繁修改页表映射的工作负载（如mmap/munmap密集型的应用），TLB Shootdown可以成为显著的性能瓶颈。

减少TLB Shootdown开销的技术

批量TLB无效化。将多个TLB无效化请求打包为一次Shootdown操作，减少IPI的总次数。Linux内核的flush_tlb_range()就采用了这种策略。
ASID/PCID避免全局Shootdown。如果修改的页表属于一个特定进程且该进程当前没有在其他核心上运行，则无需向其他核心发送Shootdown——只需在该进程下次被调度到某个核心时，分配一个新的ASID即可隐式地使旧的TLB条目失效。
惰性Shootdown。不立即发送IPI，而是设置一个标志位表示“某个核心的TLB需要刷新”。当目标核心下次执行上下文切换或返回用户态时，检查该标志位并执行TLB刷新。这减少了IPI的中断开销，但增加了陈旧映射被使用的窗口（在安全关键的场景中可能不可接受）。
硬件辅助的TLB无效化广播。一些处理器（如AMD Zen系列）在硬件层面支持TLB无效化消息的广播——操作系统执行一条指令即可通知所有核心，无需使用IPI。RISC-V的Svinval扩展也提供了类似的细粒度TLB无效化指令。

案例研究 3 — 云环境中的TLB Shootdown问题

在云计算的虚拟机环境中，TLB Shootdown的问题更加严峻。每个vCPU（虚拟CPU）可能运行在不同的物理核心上，且vCPU可能被Hypervisor暂停（preempted）。当一个Guest OS需要执行TLB Shootdown时，如果某个目标vCPU当前被Hypervisor暂停，Guest OS的IPI无法立即被处理——Guest OS可能会长时间等待确认，导致所谓的vCPU preemption problem。

Linux KVM（Kernel-based Virtual Machine）通过以下技术缓解这一问题：（1）PV-TLB（Para-Virtualized TLB）协议允许Guest OS感知vCPU的运行状态，对已暂停的vCPU跳过IPI而直接标记其TLB为脏；（2）使用ASID/VMID使得即使TLB Shootdown延迟，也不会导致安全问题（因为vCPU恢复运行时会检查ASID的一致性）。

AWS的Graviton处理器（基于ARM Neoverse）利用了AArch64的硬件广播TLB无效化（TLBI指令的“inner shareable”变体）来减少TLB Shootdown的软件开销——一条指令即可无效化所有核心中匹配特定ASID和VA范围的TLB条目，无需IPI。

三大ISA的TLB无效化指令对比

不同ISA提供了不同粒度和语义的TLB无效化指令，表表 10.14汇总了主要的差异。

功能	x86-64	AArch64	RISC-V
单页无效化	`INVLPG addr`	`TLBI VAE1IS, Xt`	`SFENCE.VMA rs1, rs2`
按ASID无效化	通过`MOV CR3`	`TLBI ASIDE1IS, Xt`	`SFENCE.VMA zero, rs2`
全TLB刷新	`MOV CR3, val`	`TLBI VMALLE1IS`	`SFENCE.VMA zero, zero`
广播范围	仅本核心（需IPI广播）	`IS`后缀：Inner Shareable域	实现定义
批量优化	无（逐个INVLPG）	多条TLBI可批量发出	Svinval扩展

AArch64在TLB管理方面的设计最为精细——TLBI指令支持约30种变体，可以按VA、ASID、VMID、VA范围等多种维度进行选择性无效化，且IS（Inner Shareable）后缀使得单条指令即可广播到所有核心，无需IPI。

x86-64的INVLPG指令只能无效化本核心的单个TLB条目，多核场景需要通过IPI软件广播。这使得x86-64在大规模多核系统上的TLB管理开销较高。Intel在近年的处理器中通过微码优化和硬件加速IPI来缓解这一问题，但在架构层面不如AArch64优雅。

RISC-V的SFENCE.VMA通过rs1和rs2参数实现了灵活的选择性无效化：当rs1=0且rs2=0时刷新全部TLB；当rs1为非零值时只无效化特定VA的条目；当rs2为非零值时只无效化特定ASID的条目。Svinval扩展进一步引入了SINVAL.VMA指令，允许多个无效化操作被SFENCE.W.INVAL和SFENCE.INVAL.IR包围形成一个批量无效化序列，减少fence的总开销。

设计提示

TLB无效化指令的设计在很大程度上决定了操作系统内存管理的效率。一个设计良好的TLB无效化接口应该：（1）支持按VA、ASID、VMID等维度的细粒度无效化，避免不必要的全局刷新；（2）支持硬件级别的多核广播，减少软件IPI的开销；（3）支持批量操作，将多个无效化请求打包处理。AArch64在这三个方面都做得最好，这是ARM在服务器市场上的一个重要架构优势。面向2030年代，随着核心数量进一步增长（256核甚至更多），TLB管理的可扩展性将成为越来越重要的设计考量。

页的大小

页大小的选择是体系结构设计中一个看似简单却影响深远的决策。它直接影响TLB覆盖范围、内部碎片、页表内存开销、Cache设计约束等多个维度。不同的ISA和操作系统在页大小的选择上做出了不同的权衡。

4 KB页的优缺点

4 KB是最经典也最广泛使用的页大小——x86从80386（1985年）开始就使用4 KB页，RISC-V的默认页大小也是4 KB，AArch64的4 KB粒度模式同样如此。4 KB页的选择有以下考量：

优点

内部碎片小。每个映射的最后一页平均浪费 $P/2 = 2\,\text{KB}$ 的空间（页尾部未使用的部分）。对于大量小文件和小数据结构，4 KB页的空间利用率最高。
页面换出粒度细。操作系统在内存压力下需要将不常用的页面换出到磁盘。4 KB的换出粒度意味着操作系统可以精确地选择最不常用的小区域进行换出，而不会因为粒度过大而换出仍在使用的数据。
CoW开销小。写时复制每次只需要复制4 KB的数据，而非2 MB或更大。
ASLR（地址空间布局随机化）的熵更高。ASLR通过随机化程序各段（代码段、数据段、堆、栈、共享库）在虚拟地址空间中的加载位置来增加攻击者猜测地址的难度。随机化的粒度受限于页大小——代码段的起始地址只能按页大小对齐。在4 KB页下，48位VA空间中可用于随机化的位数更多（例如栈的随机化可以有28位熵，即 $2^{28} \approx 2.68$ 亿种可能位置），而64 KB页将随机化熵减少4位。

缺点

TLB覆盖范围小。一个拥有64项的L1 DTLB在4 KB页下只覆盖 $64 \times 4\,\text{KB} = 256\,\text{KB}$ 的地址空间。对于工作集为数十MB甚至GB的应用（如数据库、科学计算），TLB缺失率可能很高。
Page Walk频率高。TLB覆盖范围小导致TLB缺失更频繁，进而触发更多的page table walk，消耗额外的访存带宽和延迟。在某些极端工作负载中（如图数据库的随机遍历），TLB缺失相关的开销可占总执行时间的30% $\sim$ 50%。
页表占用内存大。映射1 GB内存需要 $2^{18}$ 个PTE，即使只存储PTE本身也需要 $2^{18} \times 8\,\text{B} = 2\,\text{MB}$ 。加上多级页表的中间级开销，总页表内存可能达到数MB。在一台运行数百个容器（每个容器数十个进程）的服务器上，页表的总内存消耗可达数百MB。
Page Fault频率高。按需分页场景下，每4 KB触发一次Page Fault，而每次Page Fault的固定开销（异常处理、TLB刷新）不可忽略。映射一个256 MB的文件需要65,536次Page Fault，即使每次只有2 s也需要130 ms的总开销。
struct page内存开销。Linux内核为每个物理页帧维护一个struct page元数据结构（约64字节），4 KB页意味着需要为每TB物理内存分配约16 GB的struct page数组。

大页

大页（Huge Page）通过在页表遍历的中间级停止（设置PS/叶节点位），直接映射一个大的连续物理区域，从而将页表遍历减少一到两级，同时让TLB中一个条目覆盖更大的地址范围。大页是提升内存密集型应用性能的最重要微架构级优化之一。x86-64支持两种大页：

2 MB大页：在PD级停止（跳过PT级），VA[20:0]（21位）用作页内偏移。TLB中一项覆盖2 MB。
1 GB大页：在PDPT级停止（跳过PD和PT级），VA[29:0]（30位）用作页内偏移。TLB中一项覆盖1 GB。

大页的性能优势

大页的主要优势在于显著减少TLB缺失。以一个访问1 GB数据的工作负载为例：

页大小	所需TLB项数	64项TLB覆盖	TLB缺失率（估算）
4 KB	262,144	256 KB	高
2 MB	512	128 MB	中等
1 GB	1	64 GB	极低

实测数据表明，对于内存密集型工作负载（如数据库的Buffer Pool），使用2 MB大页可以将TLB缺失率降低90%以上，整体性能提升5% $\sim$ 30%。在HPC和机器学习训练中，使用1 GB大页映射GPU显存或大型张量数据，可以几乎完全消除TLB缺失。

除了TLB覆盖率的直接提升外，大页还带来两个额外的性能优势：（1）Page Walk深度减少——2 MB大页的page walk只需3级（跳过PT级），1 GB大页只需2级（跳过PD和PT级），即使发生TLB缺失，walk的延迟也更低；（2）Page Fault次数减少——按需分配一个2 MB大页只需1次Page Fault（而非512次4 KB页的Page Fault），固定开销被摊薄。

大页的代价

大页并非没有缺点：

内部碎片。2 MB大页的平均内部碎片为1 MB。对于仅使用几十KB内存的小进程，使用大页意味着严重的内存浪费。
物理内存碎片。操作系统需要找到连续的2 MB（或1 GB）物理内存区域来满足大页分配。在系统运行一段时间后，物理内存碎片化可能导致大页分配失败。
CoW开销大。写时复制一个2 MB的大页需要复制2 MB数据，远大于4 KB页的复制开销。在fork()-heavy的工作负载中（如PHP-FPM的进程池模型），大页的CoW开销可能导致显著的延迟抖动。
换出粒度粗。换出一个2 MB的大页到磁盘需要写入2 MB数据，且可能将仍在使用的数据也一并换出。这也是为什么Linux的THP默认不启用swap对大页的支持（直到Linux 5.14才开始实验性支持大页的swap）。
分配延迟不确定。当系统物理内存碎片化严重时，操作系统需要进行内存压缩（compaction）来整理出连续的2 MB区域，这一过程可能耗时数百毫秒甚至秒级，引入不可预测的分配延迟。

透明大页（THP）

Linux提供了透明大页（Transparent Huge Pages, THP）机制，试图在不修改应用程序的情况下自动利用大页。THP的工作方式是：当操作系统检测到一个进程的连续4 KB页面恰好可以合并为一个2 MB大页时（即512个连续的4 KB页面已经映射到连续的物理帧），操作系统在后台将它们合并（collapse）为一个大页。反过来，当大页中只有少量页面被使用时，操作系统可以将大页分裂（split）为512个4 KB小页以回收未使用的内存。

THP在实践中效果参差不齐。对于内存密集型工作负载（如Redis、MySQL），THP通常能带来正面的性能提升。但THP的后台合并/分裂操作可能引入延迟抖动（latency spike），对延迟敏感的应用（如金融交易系统）反而有害。因此，许多生产环境中的数据库部署指南建议禁用THP，转而使用显式的大页分配（hugetlbfs）。

大页的TLB实现

在微架构层面，支持多种页大小的TLB设计有两种主要方案：

分离TLB（Split TLB）：为不同页大小维护独立的TLB结构。Intel的L1 DTLB采用这种方案——96项用于4 KB页，32项用于2 MB/4 MB页，8项用于1 GB页。优点是每种页大小的TLB可以独立优化（如4 KB TLB使用较低相联度以降低延迟）。缺点是TLB资源无法在不同页大小之间灵活共享。
统一TLB（Unified TLB）：所有页大小共享同一个TLB结构，每个条目记录该翻译对应的页大小。AMD Zen 4的L2 TLB采用这种方案（2048项统一TLB）。优点是TLB项数可以根据工作负载的实际页大小分布灵活使用。缺点是TLB查找逻辑更复杂——需要同时用不同的位域来匹配不同页大小的虚拟页号。

Intel Golden Cove的L2 TLB采用了一种混合方案：2048项统一结构，支持4 KB和2 MB页共享，但内部使用特殊的哈希函数来处理不同页大小的索引差异。从微架构角度看，统一TLB的设计挑战在于：4 KB页和2 MB页的VPN长度不同（分别为36位和27位），需要为每个TLB条目存储一个"页大小"标志位，并在匹配逻辑中根据页大小选择不同的比较位域。一种常见的实现方式是使用可变长度CAM匹配——Tag中存储VPN的公共高位部分，低位的比较通过掩码（mask）来适配不同的页大小。

多页大小TLB的可变掩码匹配

在支持多种页大小的统一TLB中，可变掩码匹配（Variable Mask Matching）是一种常用的实现技术。每个TLB条目除了存储VPN和PPN外，还存储一个掩码（Mask）字段，指示VPN的哪些位需要参与比较。

以同时支持4 KB（VPN 36位）和2 MB（VPN 27位）页的TLB为例：

页大小	VPN位域	有效比较位	掩码值
4 KB	VPN[35:0]	36位全部比较	`0xF_FFFF_FFFF`
2 MB	VPN[35:9]	高27位比较，低9位忽略	`0xF_FFFF_FE00`
1 GB	VPN[35:18]	高18位比较，低18位忽略	`0xF_FFFC_0000`

匹配逻辑变为：

\text{Match} = \bigl( (\text{Input\_VPN} \oplus \text{Stored\_VPN}) \;\&\; \text{Mask} \bigr) = 0

其中 $\oplus$ 是按位异或， $\&$ 是按位与。异或的结果中，不同的位为1；掩码屏蔽了不需要比较的低位；如果掩码后的结果全为0，则匹配成功。

这种掩码匹配的硬件实现需要在每个XNOR比较器的输出上增加一个AND门来应用掩码——面积开销约增加10% $\sim$ 15%。此外，掩码字段本身需要额外的存储位（每条目增加2 $\sim$ 3位来编码页大小），进一步增加了TLB条目的总宽度。

TLB Coalescing——硬件自动合并小页

TLB Coalescing（TLB合并）是一种无需操作系统显式配置大页即可扩展TLB覆盖范围的硬件技术。当PTW检测到连续的若干4 KB页面映射到连续的物理页帧且具有相同的权限属性时，可以在TLB中用一个等效的“合并条目”来表示这些页面，使得一个TLB条目覆盖比4 KB更大的地址范围。

例如，如果虚拟页VPN=0x1000到VPN=0x1FF（共512个连续4 KB页 = 2 MB）映射到连续的物理帧PFN=0x2000到PFN=0x21FF，且所有页面的权限相同，那么TLB可以合并这512个条目为一个等效的2 MB条目：VPN=0x1000（高27位），PPN=0x2000（高31位），掩码=2 MB掩码。

Intel从Skylake开始支持的“Page Walk Coalescing”就是这种技术的一种形式。PTW在完成walk后，检查相邻的PTE是否满足合并条件（连续映射、相同权限、相同内存类型）。如果满足，则在TLB中写入一个合并后的大条目。

TLB Coalescing的优势在于对操作系统透明——不需要OS配置透明大页（THP），也不需要分配连续的物理内存。只要操作系统的伙伴系统分配器碰巧为连续虚拟页分配了连续物理帧（这在系统运行早期是常见的），TLB硬件就可以自动利用这种连续性。

但TLB Coalescing也有局限性：（1）需要PTW在walk完成后额外检查相邻PTE，增加了walk的延迟；（2）只能合并满足严格连续性和一致性条件的页面——在系统运行一段时间后，物理内存碎片化导致连续映射的概率降低；（3）合并后的条目如果其中一个页面的权限被修改（如CoW触发的写保护），整个合并条目必须被分裂，增加了管理复杂度。

不同ISA大页实现的对比

表表 10.17对比了三大ISA的大页支持方式，展示了它们在灵活性和实现复杂度之间的不同权衡。

特性	x86-64	AArch64 (4KB)	RISC-V
2 MB大页	PDE.PS=1	Level 2叶节点	Level 1叶节点
1 GB大页	PDPTE.PS=1	Level 1叶节点	Level 2叶节点
叶节点标识	PS位	Block描述符	$R
对齐要求	物理地址2MB/1GB对齐	同左	同左
大页TLB	分离TLB	统一或分离	实现定义
中间大页	无	16KB粒度下32MB	Svnapot: 64KB等

一个值得注意的区别是大页的叶节点标识方式：x86-64使用专用的PS（Page Size）位来标识中间级PTE是否为叶节点，而RISC-V更优雅地利用R/W/X位来区分——当 $R|W|X = 0$ 时为非叶节点（指针），否则为叶节点。RISC-V的方案减少了PTE中专用位的使用，但代价是不支持“不可读、不可写、不可执行”的有效叶节点页面（这种页面在实际使用中极为罕见，通常被视为无效映射）。

大页的对齐约束与操作系统分配

大页要求物理内存的分配必须满足严格的对齐约束——2 MB大页需要2 MB对齐的连续物理内存，1 GB大页需要1 GB对齐的连续物理内存。这个约束直接来自页表结构：当PDE（或PDPTE）作为叶节点时，PPN字段的低位（对应页内偏移扩展的部分）全部为0，因此物理基址必须自然对齐。

在实际操作系统中，大页的分配面临以下挑战：

碎片化问题。系统运行一段时间后，物理内存被分割成大量不连续的4 KB页帧，难以找到连续的2 MB区域。Linux内核的compaction机制尝试通过迁移页面来整理出连续区域，但这个过程耗时且不确定。
预分配 vs 动态分配。Linux提供两种大页分配方式：（1）通过hugetlbfs在系统启动时预分配（保证成功，但浪费未使用的内存）；（2）通过透明大页（THP）在运行时动态分配（灵活但可能失败或引入延迟抖动）。
1 GB大页的特殊性。1 GB大页在系统启动后几乎不可能通过碎片整理来分配——内核无法迁移1 GB区域内的所有页面。因此，1 GB大页几乎总是在内核启动参数中预分配（如hugepagesz=1G hugepages=8）。
NUMA感知。在多Socket NUMA系统中，大页应该分配在访问它的CPU所在的NUMA节点上。跨NUMA节点访问大页会引入额外的内存延迟（约增加30% $\sim$ 70%），可能抵消大页带来的TLB覆盖率优势。

案例研究 4 — Oracle数据库与大页

Oracle数据库是大页技术最典型的受益者之一。Oracle的SGA（System Global Area）通常为数十GB甚至数百GB，使用4 KB页意味着SGA的映射需要数百万个TLB项，导致严重的TLB缺失和性能下降。Oracle官方建议在Linux上使用hugetlbfs预分配2 MB大页来映射SGA。在128 GB SGA的场景下，使用4 KB页时TLB相关的CPU开销约占总CPU时间的15% $\sim$ 25%；切换到2 MB大页后，这一开销降至1% $\sim$ 3%，整体查询吞吐量提升约20%。

对于更极端的场景（如TB级别的内存数据库），1 GB大页是进一步的优化选择。SAP HANA在Linux上支持使用1 GB大页来映射其列存储引擎的数据，在2 TB内存的服务器上可以将TLB缺失降低99%以上。

16 KB页

Apple在其A7处理器（2013年，iPhone 5s）中首次采用了16 KB的页大小，此后所有的Apple芯片（A系列和M系列）都沿用了这一选择。macOS和iOS/iPadOS强制使用16 KB页，所有的应用和动态库都必须按16 KB边界对齐。

16 KB页可以看作是4 KB页与64 KB页之间的一个精心选择的折中点：

TLB覆盖范围扩大4倍

相同数量的TLB项覆盖的地址空间增大4倍：64项DTLB在4 KB页下覆盖256 KB，在16 KB页下覆盖1 MB。这对于移动设备上TLB项数受限的场景尤其重要——Apple的高性能核心L1 DTLB通常只有192项（远少于Intel/AMD的同类设计），16 KB页使其覆盖 $192 \times 16\,\text{KB} = 3\,\text{MB}$ ，已经足以覆盖多数移动应用的热数据工作集。

对VIPT Cache的影响

16 KB页对L1 Cache的微架构设计有重要影响。在VIPT（Virtually Indexed, Physically Tagged）Cache中，为了避免同义词问题（aliasing），要求Cache的每路（way）大小不超过页大小。对于4 KB页：

\text{每路大小} \leq 4\,\text{KB} \implies \text{组数} \times \text{行大小} \leq 4096\,\text{B}

以64 B行为例，每路最多64组，因此32 KB的L1 D-Cache需要至少 $32\,\text{KB} / 4\,\text{KB} = 8$ 路相联——较高的相联度增加了访问延迟和功耗。

而在16 KB页下，约束放宽为：

\text{每路大小} \leq 16\,\text{KB} \implies \text{组数} \times \text{行大小} \leq 16384\,\text{B}

同样32 KB的L1 D-Cache只需 $32\,\text{KB} / 16\,\text{KB} = 2$ 路相联即可避免同义词问题。Apple可以选择用更低的相联度实现相同大小的Cache，或者在相同相联度下实现更大的Cache——这正是Apple M系列处理器的L1 D-Cache达到128 KB的重要原因之一（128 KB / 16 KB = 8路，而在4 KB页下实现128 KB需要32路）。

对Page Table Walk延迟的影响

在16 KB粒度下，AArch64的每级页表包含 $2^{11} = 2048$ 个条目（每级索引11位），每级页表大小为 $2048 \times 8 = 16\,\text{KB}$ ——恰好等于一个16 KB页帧。48位VA下使用4级页表（或3级，取决于TnSZ配置）。相比4 KB粒度的4级页表（每级512项），16 KB粒度的每级覆盖范围更大（每级 $2^{11}$ 项 vs. $2^9$ 项），因此相同的虚拟地址空间可以用更少的级数来寻址——16 KB粒度在某些配置下只需3级遍历即可覆盖完整的48位VA空间，减少一次内存访问。

代价

16 KB页的主要代价是内部碎片增大（平均浪费8 KB vs. 4 KB页的2 KB），以及与主流Linux生态的兼容性问题。许多Linux应用和库假设4 KB页大小（如内存分配器的对齐假设、mmap的对齐参数），移植到16 KB页平台需要重新编译甚至修改代码。Android从2024年开始推进16 KB页的支持（Android 15），但向后兼容性仍然是一个挑战。

性能分析 4 — 4 KB vs. 16 KB页的SPEC CPU性能对比

在SPEC CPU2017的基准测试中，页大小的影响因工作负载特性而异：

内存密集型工作负载（如mcf、lbm、cactuBSSN）：16 KB页相比4 KB页可带来3% $\sim$ 8%的性能提升，主要来自TLB缺失率的降低。mcf的工作集约为1.5 GB，远超L1 DTLB的覆盖范围，TLB缺失是其主要性能瓶颈之一。
计算密集型工作负载（如namd、imagick、blender）：性能差异不到1%，因为这些工作负载的工作集较小且具有良好的空间局部性，TLB缺失率在两种页大小下都很低。
服务器工作负载（如数据库OLTP、Web服务器）：16 KB页的优势更加明显（5% $\sim$ 15%），因为这些工作负载通常具有大工作集和随机的访存模式。

值得注意的是，16 KB页的内部碎片代价在内存受限的移动设备上可能是一个显著问题。在iPhone/iPad上，Apple通过操作系统级别的内存压缩（Compressed Memory）和精细的内存管理来缓解这一问题。

页大小对TLB效率的影响

页大小对TLB效率的影响可以通过TLB覆盖率（TLB Reach / TLB Coverage）来量化：

\text{TLB Reach} = \text{TLB项数} \times \text{页大小}

当TLB Reach大于应用的工作集大小时，TLB几乎不会发生缺失。当TLB Reach远小于工作集时，TLB缺失率可能很高。

处理器	L1 DTLB项数	页大小	L1 DTLB Reach	L2 TLB Reach
Intel Golden Cove	96 (4 KB) + 32 (2 MB)	4 KB/2 MB	384 KB + 64 MB	$\sim$ 8 GB
AMD Zen 4	72 (4 KB) + 72 (2 MB)	4 KB/2 MB	288 KB + 144 MB	$\sim$ 4 GB
Apple M2 Avalanche	192	16 KB	3 MB	$\sim$ 48 MB
SiFive P870	64	4 KB	256 KB	$\sim$ 16 MB

从表表 10.18可以看出几个趋势：

Intel和AMD通过分离的4 KB和2 MB TLB来同时服务两种页大小，依赖操作系统和应用合理使用大页。
Apple通过16 KB页大小在不增加TLB项数的情况下获得了可观的TLB覆盖范围。
L2 TLB（通常1024 $\sim$ 4096项，全相联或高相联）提供了更大的覆盖范围作为后盾。

不同处理器L1 DTLB的Reach比较（注意y轴范围截断，4\,KB页的Reach不到1\,MB）

TLB缺失率的经验模型

TLB缺失率可以用类似Cache缺失率的经验模型来近似。假设应用的访存地址在虚拟页的粒度上服从某种工作集模型（如LRU Stack Distance模型），则TLB缺失率大致可以表示为：

\text{TLB Miss Rate} \approx \left(\frac{\text{Working Set Size}}{\text{TLB Reach}}\right)^\alpha, \quad \alpha \approx 0.5 \sim 1.0

其中 $\alpha$ 取决于访存模式的局部性特征。对于顺序访问（高空间局部性）， $\alpha$ 接近1；对于完全随机访问， $\alpha$ 趋向于与TLB项数的关系更为紧密。这个模型虽然粗糙，但揭示了一个重要的定性结论：当工作集大小远超TLB Reach时，增加页大小 $k$ 倍等价于增加TLB项数 $k$ 倍——两者对TLB缺失率的影响是等价的。然而，增加页大小是一个免费的"增加TLB项数"手段（不需要额外的硬件面积和功耗），而实际增加TLB项数则需要更大的CAM阵列、更高的功耗和更长的查找延迟。

从另一个角度看，TLB的设计面临一个基本的面积-延迟权衡：增加TLB项数可以提高覆盖率但增加访问延迟（CAM查找延迟与项数的对数成正比）。在1 $\sim$ 2个周期的延迟预算内，全相联TLB的实际项数上限约为64 $\sim$ 256项（取决于工艺节点和频率目标）。要覆盖更大的工作集，必须依赖以下策略的组合：

使用更大的页（16 KB、64 KB或2 MB大页）。
使用多级TLB（L1 TLB小而快，L2 TLB大而慢）。
使用Page Walk Cache缓存中间级页表项，减少TLB缺失的代价。
使用TLB预取（如Intel的page walk prediction），在TLB缺失发生前提前开始page walk。

这些技术将在第 11.0 章中详细讨论。

设计权衡 2 — 页大小的多维权衡

页大小的选择涉及至少五个维度的权衡：

维度	小页 (4 KB)	中页 (16 KB)	大页 (64 KB+)
TLB覆盖	最小	中等 ( $4\times$ )	大 ( $16\times$ +)
内部碎片	最小 (2 KB均)	中等 (8 KB均)	大 (32 KB均)
页表大小	最大	中等	最小
VIPT约束	最严	放宽 ( $4\times$ )	最宽松
I/O粒度	最细	中等	最粗

没有一个页大小是在所有维度上最优的——这就是为什么几乎所有现代ISA都支持多种页大小（基础页 + 大页），由操作系统根据不同的使用场景灵活选择。面向2030年代，随着CXL扩展内存和持久化内存的普及，工作集不断增大，大页和巨页（1 GB）的重要性将进一步提升。

程序保护

虚拟存储器的另一个核心功能是程序保护（Memory Protection）——控制每个虚拟页面的访问权限，防止程序执行非法的内存操作。保护机制通过页表项中的权限位实现，由处理器的MMU（内存管理单元）在每次地址转换时进行硬件级别的检查。

在微架构实现中，保护检查与地址翻译是同时进行的——当TLB命中时，保护位（R/W/X、U/S等）作为TLB条目的一部分被同时读出并检查，不增加任何额外延迟。当TLB缺失需要page table walk时，保护位从PTE中读出并与新的TLB条目一起写入TLB。只有在检测到保护违例时，才会触发异常路径——这遵循了处理器设计的一个基本原则：常见路径零开销，异常路径可以慢。

硬件描述 4 — MMU中的保护检查逻辑

在硬件层面，MMU的保护检查逻辑是一个组合逻辑电路，接收以下输入：（1）TLB条目中的保护位（R/W/X/U/G等）；（2）当前处理器的特权级别（Ring 0/3或EL0/EL1）；（3）访问类型（读/写/取指）；（4）相关的控制寄存器状态（如CR4.SMEP、CR4.SMAP、EFLAGS.AC等）。

保护检查的输出是一个单比特的"允许/拒绝"信号。在x86-64中，拒绝访问会导致#PF异常，异常码编码了具体的违规原因。检查逻辑的关键路径延迟约为2 $\sim$ 4个门延迟（gate delay），远小于TLB查找本身的延迟（通常为一个SRAM/CAM访问延迟），因此保护检查不是地址翻译的时序关键路径。

页表项中的保护位

不同的ISA在PTE中定义了略有不同的保护位集合，但核心概念是共通的：

读/写/执行权限（R/W/X）

最基本的保护是控制对页面的读取、写入和执行权限。RISC-V的PTE直接提供了独立的R、W、X位，允许8种权限组合中的有效子集。x86-64使用R/W位（0=只读，1=可读写）和NX位（1=不可执行），其组合方式略有不同但表达能力相当。AArch64在Stage 1翻译中使用AP（Access Permission）字段和UXN/PXN（User/Privileged Execute Never）位。

Accessed位与Dirty位

Accessed（A）位和Dirty（D）位用于辅助操作系统的页面置换算法。A位在页面被首次读取或写入时由硬件自动设置为1；D位在页面被首次写入时设置为1。操作系统定期扫描并清除A位，根据下次扫描时A位是否重新被设置来判断页面是否被"近期使用"过——这是LRU近似算法（Clock算法）的基础。D位告诉操作系统该页面自上次换入后是否被修改过——只有脏页面在换出时才需要写回磁盘。

不同ISA对A/D位的处理方式不同：

x86-64：A位和D位都由硬件自动设置（Hardware-managed）。处理器在page table walk过程中自动将A/D位从0修改为1，这涉及对页表内存的写操作。
RISC-V：规范允许两种方案——硬件自动设置或触发Page Fault由软件设置。如果PTE的A位为0时发生读/写/取指访问，处理器可以选择自动将A设为1（硬件方案），也可以触发Access Fault让操作系统处理（软件方案）。类似地，D位为0时的写操作可以触发Store/AMO Page Fault。
AArch64：ARMv8.1引入了硬件A/D位管理（FEAT_HAFDBS），在此之前需要软件管理。软件方案通过将未设置A位的页面标记为无效来触发Page Fault。

Global位

Global（G）位标记该页面映射在所有地址空间中都有效（如内核代码页、共享库的代码页）。当G位为1时，上下文切换时TLB中标记为Global的条目不会被刷新，避免了不必要的TLB缺失。这对性能非常重要——上下文切换后内核代码的TLB条目仍然有效，无需重新遍历页表。

Memory Protection Keys（MPK）

Intel从Skylake开始引入了内存保护密钥（Memory Protection Keys, MPK）机制。PTE的位[62:59]存储一个4位的Protection Key（共16种），每个Protection Key通过用户态可写的PKRU寄存器独立控制该组页面的读/写权限。MPK的革命性在于：修改页面权限不需要修改页表、不需要内核态切换、不需要TLB刷新——只需一条用户态指令（WRPKRU）即可在几个周期内改变一组页面的访问权限。这使得高频的权限切换（如沙箱化、内存隔离域）成为可能。

PKRU寄存器为32位，每个Protection Key占用2位（Access Disable和Write Disable），因此可以独立控制16个内存域的权限。在微架构实现上，PKRU的值被复制到TLB条目中（或在TLB查找的同时并行检查），不增加地址转换的延迟。图图 10.20展示了MPK的工作原理。

MPK的典型应用场景包括：（1）沙箱隔离——将不可信的库（如图像解码器、正则表达式引擎）的数据与主程序的数据分配在不同的Protection Key域中，在调用不可信代码前通过WRPKRU禁用主程序数据的访问权限；（2）敏感数据保护——加密密钥、密码等敏感数据只在需要时才通过WRPKRU临时解锁访问；（3）OpenJDK的虚拟线程——Java的虚拟线程可以使用MPK来隔离不同虚拟线程的栈空间，检测栈溢出。

需要注意的是，MPK并非一个完美的安全机制——WRPKRU是用户态指令，攻击者在ROP（Return-Oriented Programming）攻击中可能通过gadget链来修改PKRU值。因此，MPK更适合作为完整性保护（防止意外访问）而非安全隔离（防止恶意攻击）的工具。

用户态与内核态的隔离

虚拟存储器的一个基本安全要求是用户态代码不能访问内核态内存。在传统的x86-64设计中，内核页面与用户页面共存于同一棵页表树中——当程序运行在用户态（Ring 3）时，PTE中U/S=0（Supervisor only）的页面虽然在页表中可见，但MMU会阻止对它们的访问。

这种设计在2018年之前被认为是安全的。然而，Meltdown漏洞（CVE-2017-5754）的发现改变了一切。

Meltdown攻击原理

Meltdown利用了Intel处理器（以及部分ARM处理器）的一个微架构缺陷：在推测执行路径上，处理器在权限检查结果出来之前就已经将内核页面的数据加载到Cache中。虽然权限检查失败后推测执行的结果会被丢弃（体系结构状态回滚），但数据已经进入Cache这一事实——作为微架构侧效应（Microarchitectural Side Effect）——并不会被回滚，可以通过Cache侧信道（如Flush+Reload）被攻击者检测到。

这一漏洞的根本原因是处理器的微架构设计将性能优化（推测执行时尽早发起数据加载以减少延迟）置于安全检查（权限验证）之前——在权限检查结果可用之前，数据已经流入了处理器的微架构状态（Cache）中。这揭示了一个深层的设计矛盾：超标量乱序处理器的核心性能优势（推测执行）同时也是安全漏洞的潜在来源。

具体而言，攻击者在用户态执行以下操作：

推测性地读取一个内核地址的内容（虽然会触发异常，但在异常被处理之前...）。
使用读取到的内核数据值作为索引，访问一个用户态的探测数组（probe array）。
异常被处理，推测执行的结果被丢弃——但探测数组中被访问的那一行已经进入Cache。
攻击者逐一计时访问探测数组的每个元素，发现哪个元素的访问时间最短（在Cache中），从而推断出内核数据的值。

KPTI/KAISER防御

KPTI（Kernel Page-Table Isolation），也称KAISER，是针对Meltdown的软件防御方案。其核心思想是：为每个进程维护两棵独立的页表树：

内核态页表：包含内核和用户的全部映射（与传统设计相同）。
用户态页表：只包含用户页面的映射，以及极少量必须存在的内核页面（如系统调用入口、中断处理入口）。

当处理器运行在用户态时，CR3指向用户态页表——此时即使处理器推测执行了对内核地址的访问，由于页表中根本不存在内核页面的映射，也无法将任何内核数据加载到Cache中。当发生系统调用或中断时，处理器通过一小段"跳板代码"（trampoline）切换CR3到内核态页表——这段跳板代码本身必须同时存在于用户态和内核态页表中，是两棵页表树中唯一的交叉映射区域。

KPTI的性能代价来自每次系统调用和中断时切换CR3（约100 $\sim$ 200个周期）以及由此导致的TLB刷新。在系统调用密集型的工作负载中，KPTI可能导致5% $\sim$ 30%的性能下降。Intel的PCID（Process Context ID）机制通过为不同的页表分配不同的12位ID来减少TLB刷新的范围，部分缓解了这一开销。

硬件描述 5 — 硬件层面的Meltdown修复

Intel从Whiskey Lake（2018年Q4）和Ice Lake（2019年）开始，在硬件层面修复了Meltdown漏洞——MMU的权限检查不再允许数据在检查完成前被推测性地使用。AMD的处理器架构设计中，数据不会在权限检查通过前进入推测执行的数据通路，因此从未受到Meltdown的影响。ARM方面，Cortex-A75受到影响，但后续的Cortex-A76及更新设计都已修复。

在硬件修复Meltdown的处理器上，KPTI不再是性能必需的——Linux内核可以检测CPU是否标记了"not vulnerable to Meltdown"，并在这些处理器上自动禁用KPTI以恢复性能。

Meltdown的根源可以追溯到第 3.0 章中讨论的一个核心设计张力：导线延迟和功耗约束推动处理器采用深度流水线和激进的推测执行来维持高IPC，而推测执行窗口越深，在权限检查完成之前可能“泄露”到微架构状态中的信息就越多。从更广阔的视角看，Meltdown和Spectre系列攻击（将在第 50.0 章和第 51.0 章中从安全架构的角度进行深入讨论）揭示了一个处理器设计的根本悖论：性能优化和安全隔离在微架构层面存在内在冲突——每一条旨在加速执行的投机路径，都可能成为侧信道信息泄露的载体。KPTI和Retpoline是在软件层面为这种冲突设置的“安全护栏”，而硬件修复（如Ice Lake的MMU重设计）则是在源头消除冲突。理解这一张力是处理器架构师的核心素养之一——TLB作为页表遍历结果的Cache（第 5.0 章），其每一次命中或缺失都承载着地址翻译的正确性和安全性保证，KPTI的CR3切换机制正是通过操纵TLB的内容来实现安全隔离。

KPTI的CR3切换机制深度分析

KPTI的核心操作是在用户态与内核态之间切换CR3寄存器。x86-64的CR3寄存器在KPTI模式下被分为两个“半部”：

内核态CR3：指向包含完整内核映射和用户映射的页表基址。CR3的最低有效位之一（通常为bit 12的邻近位）被用作标识位。
用户态CR3：指向只包含用户映射和最小内核跳板代码的页表基址。两棵页表树的物理基址相差一个固定的偏移量（通常为一个页帧，即4 KB），因此从一个切换到另一个只需要翻转CR3的一个位——这是一个单条指令的原子操作。

Linux内核在x86-64上的KPTI实现（位于arch/x86/entry/calling.h）使用以下关键技术：

/* 进入内核态：将CR3从用户态页表切换到内核态页表 */
static inline void switch_to_kernel_cr3(void) {
    unsigned long cr3 = __read_cr3();
    cr3 &= ~PTI_USER_PGTABLE_MASK;  /* 清除用户态标识位 */
    __write_cr3(cr3);                 /* 原子切换 */
}

/* 返回用户态：将CR3从内核态页表切换到用户态页表 */
static inline void switch_to_user_cr3(void) {
    unsigned long cr3 = __read_cr3();
    cr3 |= PTI_USER_PGTABLE_MASK;   /* 设置用户态标识位 */
    __write_cr3(cr3);
}

CR3写入操作本身只需约20 $\sim$ 30个周期，但其引发的TLB刷新才是性能损失的主要来源。在没有PCID的处理器上，每次CR3写入会全量刷新整个TLB——所有核心的TLB条目被无条件丢弃。对于一个拥有1536项L2 TLB的处理器，每次系统调用在返回用户态后需要重新填充数百个TLB条目，每个条目的填充可能需要一次page walk（16 $\sim$ 20个周期），总代价可达数千个周期。

PCID优化的关键作用在于：当启用PCID时，Linux内核为内核态和用户态页表分配不同的PCID值（通常为相邻的两个值）。CR3切换时设置“noflush”标志位，使得TLB不被刷新——旧的TLB条目仍然保留在TLB中，只是被PCID标记为属于另一个地址空间。当再次切换回来时，之前的TLB条目仍然有效，无需重新填充。

性能分析 5 — KPTI前后系统调用密集工作负载的性能对比

以Nginx Web服务器处理短连接HTTP请求为例，定量分析KPTI对性能的影响。

步骤1：基线特征。Nginx处理一个HTTP短连接请求的典型路径涉及约10 $\sim$ 15次系统调用（accept、read、write、close等），每次系统调用产生2次CR3切换（进入内核+返回用户态）。基线每秒请求数（RPS）约为150K（单核，4 GHz处理器）。

步骤2：无PCID的KPTI开销。每次CR3切换导致TLB全量刷新，平均需重新填充约50 $\sim$ 100个TLB条目。每次请求产生约25次切换（ $\sim$ 12.5次系统调用 $\times$ 2），每次切换后的TLB重建开销约200 $\sim$ 500个周期。每请求额外开销： $25 \times 350 \approx 8750$ 周期。基线每请求约26600周期（ $4 \times 10^9 / 150000$ ），KPTI开销占比 $8750 / 26600 \approx 33\%$ 。RPS降至约 $150000 \times 0.75 \approx 113$ K，性能下降约25%。

步骤3：启用PCID的KPTI开销。PCID使得TLB不被刷新，CR3切换开销降至每次约30 $\sim$ 50个周期（仅寄存器写入和流水线序列化）。每请求额外开销： $25 \times 40 \approx 1000$ 周期。开销占比 $1000 / 26600 \approx 3.8\%$ 。RPS降至约 $150000 \times 0.96 \approx 144$ K，性能下降仅约4%。

步骤4：硬件修复后（无KPTI）。在Ice Lake等硬件修复Meltdown的处理器上，KPTI被自动禁用。无CR3切换开销，性能恢复至基线150K RPS。

步骤5：总结。PCID将KPTI的性能损失从25%降低到4%——这是一个8 $\times$ 的改善。PCID的硬件成本仅为TLB每项增加12位标签（约3%的TLB面积增加），换取了KPTI下数十倍的性能改善。这深刻体现了一个微架构设计原则：为未来的安全需求预留的硬件机制（PCID在2010年引入，远早于2018年Meltdown被发现），即使在设计时看似“多余”，也可能在未来成为关键的性能救命稻草。

Retpoline对分支预测的影响

Retpoline（Return Trampoline）是针对Spectre变体2（Branch Target Injection，BTI）的软件防御方案，由Google的Paul Turner在2018年提出。其核心思想是将所有间接分支（jmp *reg和call *reg）替换为一种利用RAS（Return Address Stack）的等价序列，从而避免攻击者通过BTB注入恶意目标地址来劫持推测执行的控制流。

Retpoline的代码转换如下：

/* 原始间接调用 */
call *rax          /* BTB可被攻击者毒化 */

/* Retpoline替换后 */
call retpoline_rax
...
retpoline_rax:
  call .target     /* push返回地址到RAS */
.pause_loop:
  pause            /* 推测执行在此无限循环 */
  lfence
  jmp .pause_loop
.target:
  mov [rsp], rax   /* 将真实目标地址覆盖栈顶 */
  ret              /* RAS预测跳到.pause_loop，实际跳到rax */

Retpoline的安全原理是：ret指令使用RAS而非BTB进行目标预测。RAS的内容由处理器自身的call/ret配对维护，攻击者无法从外部注入。推测执行路径被引导到一个包含pause和lfence的无限循环中——这个循环不访问任何敏感数据，因此不会产生可被侧信道观测到的微架构效应。

Retpoline对分支预测的影响体现在以下几个方面：

（1）RAS预测替代BTB预测。间接分支原本由BTB或ITTAGE（16.4.2 节）预测目标地址，准确率通常在70% $\sim$ 90%之间。Retpoline将其转换为ret指令，由RAS预测。但Retpoline中的ret并非正常的函数返回——它的实际目标不是调用者的下一条指令，而是被mov [rsp], rax修改过的栈顶值。因此RAS的预测一定是错误的（RAS预测跳到.pause_loop，实际跳到rax的值），每次Retpoline调用都会产生一次分支预测失败和流水线冲刷。

（2）间接分支密集代码受影响最大。C++虚函数调用、switch-case跳转表和解释器分发循环是间接分支最密集的场景。在这些代码中，Retpoline将每个间接分支从“可能预测正确”变成“一定预测错误”，性能影响可达10% $\sim$ 25%。SPEC CPU2006中的perlbench（Perl解释器）和xalancbmk（XML解析器）受影响最为显著。

（3）RAS污染。Retpoline中的额外call和ret对会扰乱RAS的正常call/ret配对，可能导致后续正常函数返回的RAS预测精度下降。为缓解这一问题，某些Retpoline实现使用call后立即在栈上修改返回地址的技巧，避免向RAS压入错误的条目。

（4）BTB中间接分支记录变无用。在正常执行中，处理器的BTB（Branch Target Buffer）为每条间接分支指令缓存其最近的目标地址（或使用更高级的ITTAGE间接目标预测器维护多个候选目标）。这些BTB/ITTAGE条目是处理器经过大量训练周期积累的“预测资产”。Retpoline将间接分支替换为ret指令后，原本BTB中为这些间接分支记录的所有目标地址历史全部变为无用——因为对应的间接分支指令已经不再存在于代码中。这意味着BTB中为间接分支分配的表项容量被浪费，这些表项本可以用来为其他分支提供更好的预测。在间接分支密集的代码中，BTB中可能有10% $\sim$ 20%的有效条目因Retpoline而失去作用。

（5）C++虚函数调用的深度影响。C++的虚函数调用是Retpoline影响最深重的场景之一，值得展开分析。每次C++虚函数调用在编译后产生一条call *[rax+offset]间接调用——先从vtable指针读取虚函数表地址，再从表中读取目标函数地址，最后执行间接调用。在没有Retpoline的情况下，BTB可以有效预测这些间接调用：由于C++程序中虚函数的实际目标通常呈现出单态（monomorphic，95%以上的调用点只有一个实际目标）或少态（oligomorphic，2 $\sim$ 5个目标），BTB的预测准确率可达85% $\sim$ 95%。

Retpoline将这些间接调用全部转换为必定预测错误的ret，使预测准确率骤降至0%。对于一个每秒执行数百万次虚函数调用的应用（如游戏引擎中的场景图遍历、浏览器的DOM操作、数据库查询引擎的算子分发），每次预测错误导致的流水线冲刷约为15 $\sim$ 25个周期（取决于流水线深度）。

以一个典型的C++密集工作负载（如Chromium浏览器渲染引擎）为例：假设每千条指令（KI）中有15条间接调用（典型值为10 $\sim$ 20 KI），在4 GHz处理器上每次Retpoline的冲刷惩罚约20个周期。无Retpoline时，BTB预测准确率90%，每KI的预测错误惩罚为 $15 \times 0.1 \times 20 = 30$ 个周期。启用Retpoline后，惩罚为 $15 \times 1.0 \times 20 = 300$ 个周期——增加了270个周期/KI。如果基线IPC为2.0（每KI需要500个周期），Retpoline使每KI的有效延迟增加到770个周期，IPC降至 $\sim$ 1.3，性能下降约35%。

这一分析解释了为什么Intel和AMD在后续处理器中引入了硬件级Spectre v2修复（如eIBRS——Enhanced Indirect Branch Restricted Speculation）来替代Retpoline：eIBRS在硬件层面确保间接分支预测不会跨越特权级泄露信息，从而允许间接分支继续使用BTB预测而无需Retpoline转换。在支持eIBRS的处理器上，Linux内核自动禁用Retpoline，间接分支的预测准确率恢复到正常水平。

（6）Retpoline与导线延迟的交互。值得注意的是，Retpoline的性能代价与处理器流水线的深度密切相关——流水线越深，每次分支预测错误的冲刷惩罚越大。回顾第 3.0 章中讨论的导线延迟对流水线深度的约束：在先进工艺节点下，全局导线延迟推动流水线级数增加，这意味着Retpoline的冲刷惩罚在更先进的工艺上可能更大。这构成了一种“反直觉”的效应：工艺进步（更深的流水线）反而放大了安全缓解机制（Retpoline）的性能代价。

从TLB的角度看（回顾第 5.0 章中TLB是页表遍历结果的Cache这一观点），Retpoline还有一个间接影响：由于Retpoline在每次间接调用时引入额外的代码序列（retpoline_rax跳板函数），程序的代码footprint增大，可能导致I-TLB（指令TLB）覆盖率下降和I-Cache缺失率上升。在代码量本身就很大的应用（如数据库服务器、JVM）中，这种间接开销可能叠加在直接的预测错误惩罚之上。

设计权衡 3 — 安全缓解机制的累积性能开销

现代处理器上运行的操作系统同时启用了多种安全缓解措施。这些措施的性能开销不是简单相加的——它们之间存在复杂的交互效应。以一个典型的Linux服务器在受Meltdown和Spectre影响的处理器（如Intel Skylake）上的综合开销为例：

缓解措施	单独开销	主要影响
KPTI（含PCID）	1% $\sim$ 5%	系统调用密集型
Retpoline	5% $\sim$ 10%	间接分支密集型
IBRS/STIBP	2% $\sim$ 8%	上下文切换密集型
SSBD（Spectre v4）	2% $\sim$ 5%	推测加载密集型
综合开销	10% $\sim$ 25%	因工作负载而异

在最坏情况下（如数据库服务器处理大量短事务——同时具有高系统调用频率、大量虚函数调用和频繁上下文切换），综合性能损失可达20% $\sim$ 25%。这意味着一代处理器的性能提升可能被安全缓解完全抵消。这一事实深刻地改变了处理器设计的优先级——从2019年起，硬件级安全修复（如第 38.0 章和第 39.0 章中讨论的违规检测与恢复机制）成为每一代新处理器必须交付的核心特性，其重要性不亚于IPC提升。

NX/XD执行保护

NX（No-Execute，AMD术语）或XD（Execute-Disable，Intel术语）是PTE中的第63位，用于标记一个页面是否允许从中取指执行。当NX/XD=1时，如果处理器试图从该页面取指执行代码，将触发异常（x86-64中为#PF，异常码指示"instruction fetch from non-executable page"）。

NX/XD保护是防御代码注入攻击的关键硬件机制。在没有NX保护的系统中，攻击者可以通过缓冲区溢出将恶意代码（shellcode）写入数据段或栈上，然后通过篡改返回地址跳转到注入的代码执行。NX保护将数据页（包括栈和堆）标记为不可执行，即使攻击者成功注入了代码，处理器也会在试图执行时触发异常。

W^X策略

NX保护的最佳实践是W^X（Write XOR Execute）策略：任何页面要么可写、要么可执行，但绝不同时拥有两种权限。这一策略确保：

代码段（.text）：可读+可执行，不可写——攻击者无法修改已有代码。
数据段（.data/.bss）和栈/堆：可读+可写，不可执行——攻击者注入的数据无法被执行。

现代操作系统和编译工具链默认启用W^X策略。少数需要在运行时生成代码的场景（如JIT编译器、动态代码生成框架）需要使用mprotect()系统调用在写入完成后将页面权限从RW切换到RX。Apple的macOS/iOS进一步限制了这种切换——在ARM64e架构上，引入了JIT映射的"写入-签名-执行"三步流程，使用PAC（Pointer Authentication Code）对JIT生成的代码进行签名验证。

NX保护的历史

NX保护的引入经历了一个有趣的历史过程。32位x86架构的原始PTE只有32位，没有为NX位预留空间。AMD在2003年发布的AMD64架构中，将PTE扩展到64位，并在第63位定义了NX位。Intel随后在Prescott（2004年）中以XD的名义支持了相同功能。在此之前，32位x86系统对代码注入攻击几乎没有硬件层面的防护——所有可读的页面都自动可执行。Linux内核在2004年引入了对NX的支持，Windows从XP SP2（2004年）开始支持DEP（Data Execution Prevention），从此数据页不可执行成为操作系统安全的基本保障。

在没有硬件NX支持的32位系统上，Linux内核通过软件模拟实现了有限的NX保护（如PaX项目的PAGEEXEC和SEGMEXEC机制），但性能开销显著。这一历史案例说明了为什么安全功能应当在硬件层面实现——硬件NX检查是零开销的，而软件模拟可能带来5% $\sim$ 15%的性能损失。

AArch64的更细粒度控制

AArch64提供了比x86-64更精细的执行权限控制：

UXN（User Execute Never）：禁止用户态执行。
PXN（Privileged Execute Never）：禁止特权态执行。PXN的引入防止了一种特定的攻击模式——攻击者通过内核漏洞跳转到用户空间的代码（这些代码以内核权限执行）。

SMEP/SMAP/PAN

除了NX/XD的页面级执行保护外，现代处理器还提供了更高层次的Supervisor/Privilege模式防护机制，防止内核代码误用或被滥用来访问用户态内存。

SMEP（Supervisor Mode Execution Prevention）

SMEP由Intel在Ivy Bridge（2012年）中引入。当CR4.SMEP=1时，处理器在Ring 0（内核态）下不能执行U/S=1（用户态）页面上的代码。没有SMEP时，一种经典的内核提权攻击是：在用户态精心布置恶意代码，然后通过内核漏洞将控制流劫持到用户态的恶意代码——由于此时处理器仍在Ring 0，恶意代码将以内核权限执行。SMEP阻断了这一攻击路径。

AArch64的等价机制是PXN位（Privileged Execute Never），其粒度更细——在每个PTE中独立设置，而x86-64的SMEP是全局启用的。

SMAP（Supervisor Mode Access Prevention）

SMAP由Intel在Broadwell（2014年）中引入。当CR4.SMAP=1时，处理器在Ring 0下不能读取或写入U/S=1的页面（除非通过STAC/CLAC指令显式打开EFLAGS.AC标志位）。SMAP防止了另一类内核漏洞利用：攻击者在用户态构造恶意数据结构，通过内核漏洞使内核指针指向用户态的恶意数据，从而欺骗内核执行恶意操作。

SMAP要求内核在需要合法访问用户态内存时（如copy_from_user()/copy_to_user()），必须显式地临时禁用SMAP保护：

static inline unsigned long
copy_from_user(void *to, const void __user *from, unsigned long n)
{
    stac();                      // 临时允许内核访问用户内存
    n = raw_copy_from_user(to, from, n);
    clac();                      // 恢复 SMAP 保护
    return n;
}

PAN（Privileged Access Never）

PAN是AArch64的等价机制（ARMv8.1引入）。当PSTATE.PAN=1时，EL1（内核态）代码不能读写EL0（用户态）页面。与SMAP类似，内核在需要合法访问用户内存时，必须通过MSR PAN, #0临时禁用PAN。

ARMv8.1还引入了一个增强版本——Enhanced PAN（EPAN），结合PXN位提供更精细的控制：只有同时满足PAN=1和PXN=0的用户态页面才会被阻止访问，给予操作系统更灵活的策略选择。

CET（Control-flow Enforcement Technology）

Intel从Tiger Lake（2020年）开始引入CET，包括两个子特性：（1）Shadow Stack——为每个线程维护一个额外的"影子栈"，只由CALL/RET指令隐式修改，用于检测返回地址篡改（ROP攻击）；（2）Indirect Branch Tracking（IBT）——要求所有间接跳转的目标必须以ENDBRANCH指令开头，防止JOP（Jump-Oriented Programming）攻击。Shadow Stack的实现依赖于虚拟存储器的保护机制——Shadow Stack页面使用一个特殊的PTE属性（位于已有保留位中），使得只有CALL/RET指令可以写入，普通Store指令对Shadow Stack页面的写入会触发#CP（Control Protection）异常。

AArch64的等价机制是GCS（Guarded Control Stack，ARMv9.4-A引入）和BTI（Branch Target Identification，ARMv8.5-A引入）。RISC-V社区也在开发类似的Zicfiss（Shadow Stack）和Zicfilp（Landing Pad）扩展。这些机制共同代表了虚拟存储器保护从"数据保护"向"控制流完整性保护"的演进方向。

从处理器设计的历史视角来看，安全保护机制的演进遵循着一个清晰的模式：首先是基本的读/写权限控制（80386，1985年），然后是执行权限控制（NX，2004年），接着是特权模式防护（SMEP/SMAP，2012 $\sim$ 2014年），再到推测执行防护（KPTI/Retpoline，2018年），最新的方向是控制流完整性（CET/BTI/Shadow Stack，2020年至今）和内存标签（MTE，ARMv8.5-A）。每一代新的保护机制都是对上一代被攻击者绕过后的加固。这一演进过程表明，安全不是一个可以"一次解决"的问题，而是一个持续的硬件-软件协同进化过程。

保护机制的性能开销

这些保护机制对正常执行路径的性能影响各不相同：

NX/XD：零性能开销——只是在MMU中增加一位检查，不影响正常的取指和数据访问。
SMEP/PXN：零性能开销——只在特权态取指时增加一位检查。
SMAP/PAN：极小开销——每次copy_from_user需要额外的STAC/CLAC指令（各约1个周期），以及在异常入口/出口处修改AC/PAN标志位。
KPTI：中等到显著开销——每次系统调用和中断需要切换CR3（约100 $\sim$ 200周期），导致TLB部分或全部失效。在系统调用密集型的工作负载中（如数据库、网络服务器），开销可达5% $\sim$ 30%。

三大ISA保护机制对比

表表 10.19汇总了x86-64、AArch64和RISC-V在程序保护方面的机制对比。

机制	x86-64	AArch64	RISC-V
读/写权限	R/W位	AP[2:1]字段	R/W位（独立）
执行权限	NX/XD (bit 63)	UXN + PXN	X位
用户/特权	U/S位	AP[1]位	U位
A/D位管理	硬件自动	硬件或软件	硬件或软件
禁止特权取指用户页	SMEP (CR4)	PXN (per-PTE)	—
禁止特权读写用户页	SMAP (CR4)	PAN (PSTATE)	SUM (sstatus)
内存保护域	MPK (16个域)	MTE标签	—
指针认证	—	PAC (ARMv8.3)	—

RISC-V相比x86-64和AArch64在硬件保护机制上更为精简。RISC-V特权规范中的SUM（Supervisor User Memory access）位位于sstatus寄存器中，功能类似SMAP/PAN——当SUM=0时，S-mode代码不能访问U=1的页面。RISC-V的设计哲学是在ISA层面保持简洁，将更复杂的保护机制留给具体实现和软件扩展。

设计提示

从处理器架构师的角度看，内存保护机制的设计应遵循以下原则：（1）保护检查应在地址转换的关键路径上完成，不增加额外的流水线级数；（2）保护位应存储在PTE/TLB项中，与地址转换同时读取和检查；（3）对于常见的合法访问模式（如内核访问内核数据、用户态访问用户数据），保护检查不应引入任何额外延迟；（4）只在违规时才触发异常——异常路径可以很慢，但正常路径必须零开销。面向2030年代，MTE（Memory Tagging Extension）、CET（Control-flow Enforcement Technology）、Shadow Stack等新兴保护机制将进一步丰富硬件安全防护的工具箱。

IOMMU与设备的虚拟地址翻译

虚拟存储器的概念并不局限于CPU——在现代处理器系统中，I/O设备（如GPU、网卡、NVMe SSD控制器）同样需要访问系统内存。IOMMU（I/O Memory Management Unit）为I/O设备提供了类似于CPU MMU的地址翻译和保护机制。

IOMMU的必要性

没有IOMMU时，I/O设备通过DMA（Direct Memory Access）直接使用物理地址访问内存。这带来了两个严重问题：

安全隔离缺失。一个恶意或有bug的设备驱动程序可以让设备通过DMA读写任意物理地址，包括其他进程甚至内核的内存——这完全绕过了CPU的虚拟存储器保护机制。
地址空间不连续。操作系统为DMA分配的物理内存可能不连续（物理帧散布在DRAM的各处），但许多设备的DMA引擎需要连续的地址空间。没有IOMMU时，操作系统必须分配物理连续的内存（如使用CMA或swiotlb），这限制了DMA缓冲区的大小并增加了内存碎片化。

IOMMU通过为每个设备（或设备组）维护一套独立的页表，将设备看到的I/O虚拟地址（IOVA）翻译为物理地址。这使得：（1）设备只能访问操作系统显式授权的物理内存区域——IOMMU的页表中不存在的映射将导致DMA事务被拒绝；（2）操作系统可以为设备呈现连续的IOVA空间，即使底层物理内存不连续。

IOMMU的实现

三大平台的IOMMU实现：

Intel VT-d（Virtualization Technology for Directed I/O）：使用与CPU页表结构类似（但不完全相同）的多级页表来翻译DMA地址。VT-d支持两级翻译（类似CPU的Stage 1 + Stage 2），允许Hypervisor对Guest的设备DMA进行地址翻译和隔离。VT-d还支持PASID（Process Address Space ID），允许设备使用进程的用户态页表进行DMA——这使得设备可以直接访问用户态虚拟地址，无需操作系统介入进行地址转换（如Intel的SVA/SVM，Shared Virtual Addressing）。
ARM SMMU（System Memory Management Unit）：ARM的IOMMU实现，功能与VT-d类似但设计风格更接近ARM的翻译方案。SMMU v3支持AArch64的所有翻译粒度（4 KB、16 KB、64 KB）和两阶段翻译，与CPU的MMU格式兼容。
AMD IOMMU：AMD的实现与Intel VT-d功能对等，同样支持两级翻译和PASID。AMD的IOMMU在其chiplet架构中位于IOD上，管理所有通过Infinity Fabric连接的I/O设备。

共享虚拟地址（SVA）

共享虚拟地址（Shared Virtual Addressing, SVA）是面向2030年代的一个重要技术方向：让I/O设备（特别是加速器）直接使用CPU进程的虚拟地址空间进行DMA，而非使用独立的I/O虚拟地址。SVA使得GPU、FPGA、智能网卡等加速器可以直接解引用CPU传递的指针，无需在用户态和设备之间维护地址映射的一致性。

SVA的硬件支撑包括：

PASID：每个DMA事务携带一个PASID标签，IOMMU根据PASID选择对应进程的页表进行翻译。
设备TLB（DevTLB/ATC）：设备端的小型TLB缓存翻译结果，减少IOMMU的翻译压力。
I/O Page Fault：当设备DMA访问一个尚未映射的虚拟地址时，IOMMU可以触发I/O Page Fault，通知操作系统执行按需分页。这允许设备访问按需分页的内存，而非要求所有DMA缓冲区都预先锁定在物理内存中。
ATS（Address Translation Service）：PCIe的ATS协议允许设备主动向IOMMU请求地址翻译，并将结果缓存在设备端的ATC（Address Translation Cache）中。后续的DMA事务可以直接使用ATC中的翻译结果，绕过IOMMU。

案例研究 5 — CXL Type-2设备的共享虚拟地址

CXL 3.0/3.1规范中的Type-2设备（如CXL-attached加速器）通过CXL.cache和CXL.mem协议与主机CPU共享一致的地址空间。Type-2设备可以缓存主机内存（通过CXL.cache协议参与一致性），也可以通过HDM（Host-managed Device Memory）让主机CPU访问设备附属内存。

在这种架构下，虚拟存储器的边界从CPU扩展到了整个CXL fabric：CPU和CXL设备看到的是同一个虚拟地址空间，地址翻译由CPU的MMU和IOMMU协同完成。CXL 3.0引入的Back-Invalidate（BI）机制允许CXL设备对CPU的Cache进行无效化操作——这意味着地址翻译和Cache一致性正在跨越芯片边界深度融合，这将是2030年代处理器架构的一个核心主题。

IOMMU的页表遍历与CPU PTW的差异

IOMMU的页表遍历（I/O Page Table Walk）与CPU的PTW在设计上有几个重要差异：

延迟敏感性不同

CPU的PTW延迟直接影响处理器流水线的性能——每增加一个周期的PTW延迟都可能降低IPC。因此CPU的PTW设计追求最低延迟，使用L1 D-Cache加速、Page Walk Cache、并行PTW等技术。相比之下，IOMMU的PTW延迟被I/O事务的总延迟（通常数十到数百纳秒）所掩盖——一次PCIe DMA事务的端到端延迟约为200 $\sim$ 500 ns，IOMMU的PTW延迟（约50 $\sim$ 200 ns）只是其中一部分。因此，IOMMU的PTW设计更注重吞吐量（并行处理大量DMA请求）而非单次延迟。

页表格式可能不同

Intel VT-d的I/O页表格式与CPU页表格式相似但不完全相同——例如VT-d页表支持不同的“domain”（类似于ASID），并且其PTE中的一些控制位与CPU PTE不同（如VT-d特有的“snoop behavior”位控制DMA的Cache一致性行为）。AMD的IOMMU使用与CPU完全相同的页表格式（MOESI页表），使得同一套页表可以被CPU和IOMMU共享——这简化了SVA的实现。

TLB结构不同

IOMMU内部也有TLB（称为IOTLB或ATC），用于缓存I/O地址的翻译结果。但IOTLB的组织方式与CPU TLB有所不同：

容量更大但延迟要求更宽松。IOTLB通常有数千到数万个条目（远大于CPU的L1 TLB），因为I/O设备可能同时有大量活跃的DMA映射。
设备端TLB（DevTLB/ATC）。PCIe ATS（Address Translation Service）允许PCIe设备在设备端维护一个本地TLB——设备通过ATS请求向IOMMU查询翻译结果，并将结果缓存在设备端的ATC中。后续的DMA事务可以直接使用ATC中的翻译，绕过IOMMU。当映射被修改时，IOMMU通过ATS的Invalidation消息通知设备清除ATC中的旧条目。
IOTLB Shootdown。当操作系统修改了I/O页表映射后，需要通知IOMMU清除IOTLB中的旧条目（类似CPU的TLB Shootdown）。IOMMU的TLB Shootdown通过MMIO写操作触发（如VT-d的QI——Queued Invalidation接口），延迟通常比CPU核心间的IPI更高（数百纳秒到数微秒）。对于延迟敏感的设备（如RDMA网卡），频繁的IOTLB Shootdown可能成为性能瓶颈。

性能分析 6 — IOMMU对DMA延迟的影响

IOMMU引入的翻译开销对不同类型的I/O设备有不同的影响：

高带宽块设备（如NVMe SSD）：DMA传输的数据量大（通常4 KB $\sim$ 128 KB），IOMMU翻译的固定开销被大传输量摊薄。典型影响： $<$ 1%。
低延迟网络设备（如100G/400G RDMA网卡）：每个DMA事务可能只传输几十字节（如RDMA的小消息），IOMMU翻译的固定延迟占比显著。启用IOMMU可能增加10% $\sim$ 30%的端到端延迟，这对HPC和金融交易系统不可接受。因此，这些场景通常使用ATS/ATC来缓存翻译结果，或使用PASID+SVA来共享CPU页表避免额外的I/O页表walk。
GPU：现代GPU通过PCIe BAR或CXL接口访问系统内存，IOMMU的翻译开销对GPU的内存带宽有一定影响。NVIDIA的GPU支持ATS来缓解IOMMU开销；AMD的GPU通过XNACK机制支持按需分页的GPU内存访问（类似CPU的Page Fault），其中IOMMU的I/O Page Fault处理延迟是关键指标。

地址转换的性能总结

本节从量化的角度总结地址转换对处理器性能的影响，为处理器架构师提供设计决策的参考数据。

各级翻译结构的延迟与覆盖范围

表表 10.20汇总了现代处理器中地址转换各级结构的典型延迟和覆盖范围，提供了一个从快速路径到最慢路径的完整延迟图景。

结构	延迟	容量	覆盖范围	组织方式
L1 dTLB	1–2 cyc	64–96项	256–384 KB	全相联
L1 iTLB	1–2 cyc	48–64项	192–256 KB	全相联
L2 sTLB	6–8 cyc	1024–4096项	4–16 MB	8–16路组相联
Page Walk Cache	1–2 cyc	32–256项	—	分级或统一
PTW（L1D命中）	16–20 cyc	—	—	4级串行
PTW（L2命中）	40–80 cyc	—	—	4级串行
PTW（DRAM）	800–1600 cyc	—	—	4级串行
Page Fault（minor）	2K–10K cyc	—	—	软件处理
Page Fault（major）	$>10^6$ cyc	—	—	含磁盘I/O

从表中可以清楚地看到，TLB命中路径（1 $\sim$ 2周期）与最坏情况的page walk（1600周期）之间存在3个数量级的延迟差异。这意味着即使很小的TLB缺失率增加（如从0.1%增加到1%），也可能对处理器性能产生显著影响。这也解释了为什么处理器设计者在TLB的容量、组织方式和页大小支持方面投入了如此多的优化努力。

三大ISA的地址转换配置总结

表表 10.21为处理器设计者提供一份完整的三大ISA地址转换配置参考，涵盖了本章讨论的所有关键参数。

面向2030年代的地址转换挑战

面向2030年代，地址转换子系统面临以下核心挑战：

工作集持续增长

云计算虚拟机的内存配置已达数百GB甚至TB级别，数据库（如SAP HANA、Oracle Exadata）的内存池通常为数TB。即使使用2 MB大页，2 TB的工作集也需要 $2 \times 10^6 / 2048 \approx 1000$ 个TLB条目——这超过了大多数L2 sTLB的大页容量。1 GB大页可以将条目需求减少到约2000个，但1 GB大页的分配和管理在操作系统中仍然不够成熟。

页表深度可能进一步增加

x86-64的五级页表（57位VA）和RISC-V的Sv57已经需要5次串行内存访问。如果未来出现六级页表（支持66位VA），page walk延迟将进一步增加。Page Walk Cache和推测性page walk技术将变得更加重要。

虚拟化环境的翻译开销

随着云计算中嵌套虚拟化（Nested Virtualization，在VM中运行VM）的需求增加，地址翻译可能涉及三级甚至更多级的嵌套页表遍历。每增加一级嵌套，最坏情况的walk次数都会乘法级增长。硬件优化（如Combined TLB、Stage 2 TLB）和软件优化（如Shadow Paging、直通映射）的重要性将持续上升。

安全与隔离的新需求

机密计算（Intel TDX、AMD SEV-SNP、ARM CCA/RME）要求在地址翻译的每一步都进行额外的安全检查（如加密页表的完整性验证），这增加了翻译延迟。ARM的Memory Tagging Extension（MTE）在每次内存访问时需要检查4位标签，这些标签可能需要在TLB条目中额外存储。

异构计算的统一地址空间

CXL、UCIe和PCIe 6.0正在推动CPU、GPU、FPGA和智能网卡共享统一的虚拟地址空间。这要求IOMMU、设备TLB和CPU TLB之间保持高效的一致性——当CPU修改页表映射时，设备端的DevTLB也需要及时更新。跨设备的TLB Shootdown（通过ATS/PRI协议）的延迟远高于CPU核心之间的Shootdown。

可变页大小的硬件-软件协同

面向2030年代，页大小的管理可能从静态配置转向动态自适应。Intel的TLB Coalescing技术已经展示了硬件自动合并连续小页为等效大页的可能性，但当前的实现仍有局限（依赖物理连续性和权限一致性）。未来可能出现更激进的方案：（1）硬件自动检测热区域并建议操作系统使用大页；（2）操作系统根据TLB缺失率的实时监控动态调整页大小；（3）混合页大小的TLB设计，允许单个TLB条目灵活表示4 KB到1 GB范围内的任意2的幂次页大小。RISC-V的Svnapot扩展是这个方向的一个有趣尝试，它通过NAPOT机制在4 KB和2 MB之间提供了中间粒度（如64 KB），减少了"要么4 KB要么2 MB"的二选一限制。

页表格式的简化与统一

当前三大ISA的页表格式各有差异（x86-64使用PS位、AArch64使用描述符类型字段、RISC-V使用R|W|X位来区分叶/非叶节点），这增加了跨平台软件和硬件IP的复杂度。RISC-V社区正在讨论Svadu（硬件A/D位更新）和Ssnpm（指针遮蔽）等扩展，试图在保持简洁的同时逐步补齐与x86-64和AArch64在功能上的差距。面向chiplet时代，如果不同chiplet使用不同的ISA（如CPU使用x86-64、加速器使用RISC-V），统一的页表格式将大大简化跨chiplet的一致性域管理。CXL标准在这方面做出了重要贡献——CXL.mem定义了一套与ISA无关的内存访问语义，使得不同ISA的处理器可以通过统一的CXL协议共享内存地址空间。

本章小结

虚拟存储器是连接软件与硬件的关键桥梁，其设计质量直接影响处理器的性能、安全性和可编程性。本章从处理器微架构设计者的视角，系统深入地讨论了以下内容：

虚拟地址与物理地址的关系——虚拟存储器通过地址转换为每个进程提供独立、连续的地址空间，实现进程间隔离、按需分页、写时复制等核心功能。虚拟地址空间的稀疏性是多级页表设计的根本动机。
多级页表的详细设计——从单级页表的512 GB空间爆炸问题出发，推导出多级页表的必要性。深入分析了“每级页表恰好一个物理页帧”这一核心设计约束的来源和意义，详细展示了页表遍历的地址计算过程和伪代码算法。
三大ISA的页表实现——x86-64的四级/五级页表（含PCID和Page Walk Cache机制）、AArch64的灵活翻译方案（三种粒度、双页表基址、两阶段翻译）、RISC-V的Sv39/Sv48/Sv57三种模式（含Svnapot和Svinval扩展）。通过详细的数值示例展示了x86-64和RISC-V Sv39的完整遍历过程。
PTE位域的硬件机制——详细分析了A/D位的硬件自动更新机制（包括原子性保证和多核竞争处理）、大页的页表实现（通过中间级叶节点跳过低级遍历）、以及RISC-V PTE各位域的精确硬件语义。
Page Table Walker的微架构设计——PTW状态机的结构、并行PTW实例、Page Walk Cache的分级组织和命中率分析、PTW与Data Cache的交互和page walk pollution问题、推测性page walk技术。
ASID/PCID与地址空间标识——ASID解决TLB冷启动问题的机制、ASID位宽的面积-功耗权衡、Global位与ASID的交互、ASID回卷和惰性分配策略、VMID与虚拟化嵌套页表遍历的24次最坏情况分析。
TLB的CAM硬件结构——全相联TLB的XNOR+AND匹配线电路、CAM功耗的量化估算（预充电-评估模型）、组相联TLB对比较器数量的300倍减少效果。
地址转换的完整流程——VIPT并行的TLB+Cache流水线、多级TLB缺失处理层次、TLB缺失对乱序执行的影响和隐藏策略、TLB缺失率对IPC的量化影响模型。
TLB一致性与TLB Shootdown——多核TLB一致性的IPI机制、Shootdown的性能开销和优化技术、云环境中的vCPU preemption问题。
页大小的多维权衡——4 KB、16 KB、64 KB基础页以及2 MB、1 GB大页在TLB覆盖率、内部碎片、Cache设计约束之间的权衡。多页大小TLB的可变掩码匹配和TLB Coalescing技术。
程序保护机制——从PTE中的基本保护位到KPTI、SMEP/SMAP、PAN、MPK、CET/GCS等现代安全防护，构成了从硬件到软件的多层防御体系。
IOMMU与SVA——I/O设备的地址翻译和保护、共享虚拟地址（SVA）技术、CXL Type-2设备的统一地址空间。

本章建立的虚拟存储器知识体系可以用以下几个关键数字来总结，这些数字对处理器设计决策至关重要：

1 $\sim$ 2周期：TLB命中时的地址转换延迟——这是设计目标。
16 $\sim$ 20周期：4级page walk在L1 D-Cache全部命中时的延迟——PWC和多级TLB的目标是接近这个值。
800 $\sim$ 1600周期：4级page walk在DRAM全部缺失时的最坏延迟——这是必须避免的灾难场景。
24次内存访问：虚拟化环境下4级Guest + 4级Host嵌套page walk的最坏情况——TLB在虚拟化中的重要性不言而喻。
512 GB：48位VA、4 KB页、单级页表的不可接受开销——多级页表将其压缩到 $\sim$ 400 KB。
3328：64项全相联TLB、52位匹配宽度时的XNOR比较器数量——CAM的面积和功耗约束限制了L1 TLB的容量。
69%：大内存数据库在4 KB页下可能遭受的IPC下降——大页可以将这一损失降至 $<$ 1%。

面向2030年代的处理器架构师需要深刻理解虚拟存储器的全栈设计——从ISA层面的页表格式定义，到微架构层面的TLB/PTW/PWC硬件实现，再到操作系统层面的页表管理和大页策略。虚拟存储器不是一个“设计好就不再改变”的静态子系统，而是随着工作负载特征（工作集增长、虚拟化层次加深、安全需求提升）和技术演进（CXL、chiplet、机密计算）持续发展的动态领域。

本章建立了虚拟存储器的概念和页表硬件基础。下一章（第 11.0 章）将深入TLB的微架构设计——TLB是虚拟存储器在每一次访存操作中的性能守门人，其设计质量直接决定了地址转换的延迟是1个周期还是1000个周期。TLB本质上是页表条目的专用Cache（回顾第 5.0 章中讨论的Cache层次设计原则），但其全相联/高相联组织、多级层次和与数据Cache流水线的并行化需求使其成为微架构中最精密的组件之一。本章讨论的PCID/ASID、大页和安全保护位将在TLB设计中得到直接的硬件体现。

虚拟存储器 ​

虚拟存储器的概念 ​

虚拟地址与物理地址 ​

规范地址 ​

虚拟存储器的用途 ​

进程间地址隔离 ​

简化编程模型 ​

按需分页与过量分配 ​

内存映射文件与共享库 ​

写时复制 ​

虚拟化中的嵌套页表 ​

页与页帧 ​

页大小的选择 ​

页帧号的物理意义 ​

地址转换 ​

单级页表 ​

单级页表的致命缺陷——内存开销 ​

多级页表 ​

页表级数的最优选择 ​

级数的选择 ​

多级页表的空间节省分析 ​

“每级恰好一页”的设计约束 ​

页表遍历的地址计算 ​

反向页表 ​

x86-64的四级与五级页表 ​

四级页表（48位虚拟地址） ​

CR3寄存器的格式 ​

x86-64四级页表的遍历步骤 ​

遍历的具体数值示例 ​

PTE的格式 ​

PTE中Accessed/Dirty位的硬件更新机制 ​

大页（Huge Page）的页表实现细节 ​

五级页表（57位虚拟地址） ​

PCID/ASID机制——地址空间标识符的深入分析 ​

没有ASID时的问题 ​

ASID解决方案 ​

ASID位宽的权衡 ​

Global位与ASID的交互 ​

ASID回卷与TLB批量刷新 ​

VMID——虚拟化环境的双层标识 ​

嵌套页表遍历（2D Page Walk）的延迟分析 ​

Page Table Walker硬件 ​

硬件PTW vs 软件TLB Refill的历史演进 ​

PTW状态机的结构 ​

并行PTW ​

Page Walk Cache（PWC） ​

PTW与Cache的交互 ​

推测性Page Walk ​

AArch64的翻译方案 ​

两套页表基址 ​

TCR_EL1配置 ​

16 KB粒度的优势 ​

三大ISA页表遍历复杂度的量化对比 ​

AArch64 Stage 2翻译与嵌套页表 ​

TLB的CAM硬件结构 ​

全相联TLB的CAM结构 ​

CAM匹配逻辑的电路结构 ​

CAM的功耗分析 ​

组相联TLB——减少比较器数量 ​

LVA与LPA扩展 ​

RISC-V的Sv39/Sv48/Sv57 ​

satp寄存器 ​

RISC-V PTE格式 ​

各位域的硬件使用方式详解 ​

Sv39的遍历过程 ​

Sv39遍历的完整数值示例 ​

Svnapot扩展 ​

Svinval扩展 ​

Sv48与Sv39的PTW差异 ​

Page Fault的处理 ​

按需分页（Demand Paging） ​

页面换入（Page-in / Swap-in） ​

写时复制（Copy-on-Write） ​

保护违例（Protection Violation） ​

Instruction Page Fault ​

Page Fault的性能影响 ​

Page Fault与超标量流水线的交互 ​

A/D位在页面置换中的作用 ​

页表在Cache层次中的位置 ​

页表项的Cache行为 ​

虚拟存储器

虚拟存储器的概念

虚拟地址与物理地址

规范地址

虚拟存储器的用途

进程间地址隔离

简化编程模型

按需分页与过量分配

内存映射文件与共享库

写时复制

虚拟化中的嵌套页表

页与页帧

页大小的选择

页帧号的物理意义

地址转换

单级页表

单级页表的致命缺陷——内存开销

多级页表

页表级数的最优选择

级数的选择

多级页表的空间节省分析

“每级恰好一页”的设计约束

页表遍历的地址计算

反向页表

x86-64的四级与五级页表

四级页表（48位虚拟地址）

CR3寄存器的格式

x86-64四级页表的遍历步骤

遍历的具体数值示例

PTE的格式

PTE中Accessed/Dirty位的硬件更新机制

大页（Huge Page）的页表实现细节

五级页表（57位虚拟地址）

PCID/ASID机制——地址空间标识符的深入分析

没有ASID时的问题

ASID解决方案

ASID位宽的权衡

Global位与ASID的交互

ASID回卷与TLB批量刷新

VMID——虚拟化环境的双层标识

嵌套页表遍历（2D Page Walk）的延迟分析

Page Table Walker硬件

硬件PTW vs 软件TLB Refill的历史演进

PTW状态机的结构

并行PTW

Page Walk Cache（PWC）

PTW与Cache的交互

推测性Page Walk

AArch64的翻译方案

两套页表基址

TCR_EL1配置

16 KB粒度的优势

三大ISA页表遍历复杂度的量化对比

AArch64 Stage 2翻译与嵌套页表

TLB的CAM硬件结构

全相联TLB的CAM结构

CAM匹配逻辑的电路结构

CAM的功耗分析

组相联TLB——减少比较器数量

LVA与LPA扩展

RISC-V的Sv39/Sv48/Sv57

satp寄存器

RISC-V PTE格式

各位域的硬件使用方式详解

Sv39的遍历过程

Sv39遍历的完整数值示例

Svnapot扩展

Svinval扩展

Sv48与Sv39的PTW差异

Page Fault的处理

按需分页（Demand Paging）

页面换入（Page-in / Swap-in）

写时复制（Copy-on-Write）

保护违例（Protection Violation）

Instruction Page Fault

Page Fault的性能影响

Page Fault与超标量流水线的交互

A/D位在页面置换中的作用

页表在Cache层次中的位置

页表项的Cache行为