从 Intel 上的 CPUID 结果了解 TLB答案

【问题标题】：Understanding TLB from CPUID results on Intel从 Intel 上的 CPUID 结果了解 TLB
【发布时间】：2020-01-27 10:32:45
【问题描述】：

我正在探索 cpuid 指令的叶 0x02 并提出了一些问题。有一个表 in the documentation 描述了 cpuid 结果对 TLB 配置的意义。他们在这里：

案例 1

56H TLB Data TLB0: 4 MByte pages, 4-way set associative, 16 entries
[...]
B4H TLB Data TLB1: 4 KByte pages, 4-way associative, 256 entries

是不是说TLB只有2级？某x86厂商决定提供3级TLB，如何查询TLB缓存的级数？

案例2

57H TLB Data TLB0: 4 KByte pages, 4-way associative, 16 entries
[...] 
B4H TLB Data TLB1: 4 KByte pages, 4-way associative, 256 entries

这里的“4-way associative”只是一个拼写错误，意思是“4-way set associative”吗？

案例 3

55H TLB Instruction TLB: 2-MByte or 4-MByte pages, fully associative, 7 entries
[...]
6AH Cache uTLB: 4 KByte pages, 8-way set associative, 64 entries
6BH Cache DTLB: 4 KByte pages, 8-way set associative, 256 entries

DTLB 是否代表数据 TLB？ uTLB 是什么意思？优步-TLB？这里考虑哪个 TLB 缓存级别？

案例4

C1H STLB Shared 2nd-Level TLB: 4 KByte/2MByte pages, 8-way associative, 1024 entries

这是否意味着在这种情况下第二级 TLB 在所有内核之间共享？那么当没有明确指定时，TLB 缓存核心是私有的吗？

【问题讨论】：

1.是的，主流 x86 CPU 仍然“仅”使用 2 级 TLB，第二级是统一的（指令/数据）。没有像读/写数据缓存那样的共享（内核之间）第 3 级。您可以独立于您实际查看的 CPU 的 CPUID 进行查找，例如7-cpu.com/cpu/Skylake.html 或 realworldtech.com/haswell-cpu/5。 IDK 为什么有些人说“设置”关联而其他人没有；这对 AFAIK 来说并不重要。
是的，DTLB = 数据 TLB。 IDK uTLB 是什么；在 Intel CPU 上，uop 缓存是虚拟寻址的，因此它不需要 TLB。不确定 Ryzen 的 uop-cache 是做什么的。这是什么CPU用的？我发现software.intel.com/en-us/vtune-amplifier-help-utlb-overhead 并没有真正解决问题。似乎是说 UTLB = 一级数据 TLB，但措辞也与它作为 L1dTLB 未命中的替代兼容，该未命中也被该指标计算在内。也许它的意思是“微型 TLB”，就像只有几个条目的小型/快速 TLB，与更大的 L2TLB 相比
是的，就像我说的那样，就像我为 Skylake（包括 Kaby Lake）提供给您的链接中所说的那样，L2TLB 是统一的。只有 L1iTLB 和 L1dTLB 被拆分。
如果条目的数量 > 方式的数量，它总是设置关联的。 X（方式）* Y（组）= X*Y 条目。
@PeterCordes 我还找到了关于 TLB 的 wikichip.org/wiki/intel/microarchitectures/kaby_lake 资源。 注意：CPUID 叶 2 (EAX=02H) 错误地将 STLB 报告为“6 路”。 Kaby Lake 勘误表 KBL096 建议软件简单地忽略该值。 实际上是 12 路关联。 cpuid 所有 Kaby Lake cpus 的错误？

标签： assembly x86 x86-64 tlb cpuid

【解决方案1】：

在某些x86厂商的情况下如何查询TLB缓存的级别数决定提供 3 级 TLB？

Leaf 0x2 可能仅在 Intel 处理器上返回 TLB 信息。它保留在所有当前的 AMD 处理器上。在所有当前的 Intel 处理器上，没有一个数字可以告诉您 TLB 级别的数量。确定级别数的唯一方法是枚举所有与 TLB 相关的cpuid 叶或子叶。以下算法适用于所有当前支持 cpuid 指令的 Intel 处理器（包括 Ice Lake、Goldmont Plus 和 Knights Mill）：

检查在 EAX 设置为叶 0x2 的情况下执行 cpuid 时返回的四个寄存器 EAX、EBX、ECX 和 EDX 中的任何一个中是否存在值 0xFE。
如果 0xFE 不存在，枚举四个寄存器中的所有字节。根据 Intel 手册第 2 卷（编号 325383-070US）的表 3-12，将有一个或两个可以缓存 4KB 翻译的数据 TLB 描述符。英特尔手册对可能缓存数据访问转换的 TLB 使用了以下不同名称：Data TLB、Data TLB0、Data TLB1、DTLB、uTLB 和 Shared 2nd-Level TLB。如果有两个这样的描述符，那么级别数是两个。 TLB 号数较多的描述符是二级TLB 的描述符。如果只有一个这样的描述符，则级别数为 1。
如果0xFE存在，则需要从cpuidleaf 0x18获取TLB信息。枚举所有有效子叶，直到最大有效子叶数。如果至少有一个子叶，其 EDX 的最低两位有效位等于 11，则 TLB 级数为 2。否则，TLB 级数为 1。

Ice Lake 和 Goldmont Plus 处理器的 TLB 信息存在于叶 0x18 中。该叶子在编码 TLB 信息方面提供了更大的灵活性。所有其他当前 Intel 处理器的 TLB 信息都存在于叶 0x2 中。我不知道 Knights Mill（如果有人可以访问 Knights Mill，请考虑分享 cpuid 转储）。

确定 TLB 级别的数量不足以完全描述级别之间的关系。当前的英特尔处理器实现了两种不同的 2 级 TLB 层次结构：

二级 TLB 可以缓存数据加载（包括预取）、数据存储和指令提取的转换。在这种情况下，二级 TLB 称为“共享二级 TLB”。
二级 TLB 可以缓存数据加载和存储的转换，但不能缓存指令提取。在这种情况下，二级 TLB 被称为以下任何一种：Data TLB、Data TLB1 或 DTLB。

我将讨论几个基于来自InstLatx64 的cpuid 转储的示例。在启用超线程的 Haswell 处理器之一上，叶子 0x2 在四个寄存器中提供以下信息：

76036301-00F0B5FF-00000000-00C10000

没有 0xFE，所以 TLB 信息存在于这个叶子本身中。根据表3-12：

76: Instruction TLB: 2M/4M pages, fully associative, 8 entries
03: Data TLB: 4 KByte pages, 4-way set associative, 64 entries
63: Data TLB: 2 MByte or 4 MByte pages, 4-way set associative, 32 entries and a separate array with 1 GByte pages, 4-way set associative, 4 entries
B5: Instruction TLB: 4KByte pages, 8-way set associative, 64 entries
C1: Shared 2nd-Level TLB: 4 KByte/2MByte pages, 8-way associative, 1024 entries

其他字节与 TLB 无关。

与英特尔优化手册（编号 248966-042b）的表 2-17 相比存在一处差异。表 2-17 提到了 4KB 条目的指令 TLB 有 128 个条目，4 路关联，并且在两个超线程之间动态分区。但是 TLB 转储说它是 8 路关联的，只有 64 个条目。 128 个条目的 4 路 ITLB 实际上没有编码，所以我认为手册是错误的。反正C1显示有两层TLB，第二层缓存数据和指令翻译。

在 Goldmont 处理器之一上，叶子 0x2 在四个寄存器中提供以下信息：

6164A001-0000FFC4-00000000-00000000

这里是TLB相关字节的解释：

61: Instruction TLB: 4 KByte pages, fully associative, 48 entries
64: Data TLB: 4 KByte pages, 4-way set associative, 512 entries
A0: DTLB: 4k pages, fully associative, 32 entries
C4: DTLB: 2M/4M Byte pages, 4-way associative, 32 entries

4KB 页面有两个数据 TLB，一个有 512 个条目，另一个有 32 个条目。这意味着处理器有两个级别的 TLB。第二层称为“Data TLB”，因此只能缓存数据翻译。

优化手册的表 19-4 提到 Goldmont 中的 ITLB 支持大页面，但 TLB 信息中不存在此信息。数据TLB信息与手册表19-7一致，只是手册中将“数据TLB”和“DTLB”分别称为“DTLB”和“uTLB”。

在 Knights Landing 处理器之一上，叶子 0x2 在四个寄存器中提供以下信息：

6C6B6A01-00FF616D-00000000-00000000
6C: DTLB: 2M/4M pages, 8-way set associative, 128 entries
6B: DTLB: 4 KByte pages, 8-way set associative, 256 entries
6A: uTLB: 4 KByte pages, 8-way set associative, 64 entries
61: Instruction TLB: 4 KByte pages, fully associative, 48 entries
6D: DTLB: 1 GByte pages, fully associative, 16 entries

所以有两个 TLB 级别。第一个由不同页面大小的多个结构组成。 4KB 页面的 TLB 称为 uTLB，其他页面大小的 TLB 称为 DTLB。第二级TLB称为DTLB。这些数字和名称与手册中的表 20-3 一致。

Silvermont 处理器提供以下 TLB 信息：

61B3A001-0000FFC2-00000000-00000000
61: Instruction TLB: 4 KByte pages, fully associative, 48 entries
B3: Data TLB: 4 KByte pages, 4-way set associative, 128 entries
A0: DTLB: 4k pages, fully associative, 32 entries
C2: DTLB: 4 KByte/2 MByte pages, 4-way associative, 16 entries

此信息与手册一致，C2除外。我认为应该说“4 MByte/2 MByte”而不是“4 KByte/2 MByte”。这可能是手册中的错字。

英特尔 Penryn 微架构是一个示例，其中 TLB 信息使用名称 TLB0 和 TLB1 来指代第一级和第二级 TLB：

05: Data TLB1: 4 MByte pages, 4-way set associative, 32 entries
B0: Instruction TLB: 4 KByte pages, 4-way set associative, 128 entries
B1: Instruction TLB: 2M pages, 4-way, 8 entries or 4M pages, 4-way, 4 entries
56: Data TLB0: 4 MByte pages, 4-way set associative, 16 entries
57: Data TLB0: 4 KByte pages, 4-way associative, 16 entries
B4: Data TLB1: 4 KByte pages, 4-way associative, 256 entries

较旧的英特尔处理器具有单级 TLB 层次结构。例如，这里是 Prescott 的 TLB 信息：

5B: Data TLB: 4 KByte and 4 MByte pages, 64 entries
50: Instruction TLB: 4 KByte and 2-MByte or 4-MByte pages, 64 entries

所有 Intel 80386 处理器和部分 Intel 80486 处理器都包含单级 TLB 层次结构，但不支持 cpuid 指令。在 80386 之前的处理器上，没有分页。如果您希望上述算法适用于所有 Intel x86 处理器，您还必须考虑这些情况。英特尔文档编号 241618-025 标题为“处理器标识和 CPUID 指令”，可在here 找到，在第 7 章中讨论了如何处理这些情况。

我将讨论一个示例，其中 TLB 信息存在于叶 0x18 而不是叶 0x2 中。就像我之前所说的那样，现有的英特尔处理器中唯一在 0x18 中存在 TLB 信息的是 Ice Lake 和 Goldmont Plus 处理器（可能还有 Knights Mill）。 Ice Lake 处理器的叶子 0x2 转储是：

00FEFF01-000000F0-00000000-00000000

有一个 0xFE 字节，因此 TLB 信息存在于更强大的叶子 0x18 中。叶 0x18 的子叶 0x0 指定最大有效子叶为 0x7。以下是子叶 0x0 到 0x7 的转储：

00000007-00000000-00000000-00000000 [SL 00]
00000000-00080007-00000001-00004122 [SL 01]
00000000-0010000F-00000001-00004125 [SL 02]
00000000-00040001-00000010-00004024 [SL 03]
00000000-00040006-00000008-00004024 [SL 04]
00000000-00080008-00000001-00004124 [SL 05]
00000000-00080007-00000080-00004043 [SL 06]
00000000-00080009-00000080-00004043 [SL 07]

英特尔手册描述了如何解码这些位。每个有效的子叶都描述了一个 TLB 结构。如果 EDX 的最低 5 位不全为零，则子叶是有效的（即描述 TLB 结构）。因此，子叶 0x0 无效。接下来的七个子叶都是有效的，这意味着一个 Ice Lake 处理器中有 7 个 TLB 描述符。 EDX 的最低 5 位指定 TLB 的类型，接下来的 3 位指定 TLB 的级别。通过对子叶位进行解码得到以下信息：

[SL 01]：描述一级指令 TLB，它是一个 8 路完全关联缓存，能够缓存 4KB、2MB 和 4MB 页面的翻译。
[SL 02]：最低有效五位表示数字 5，根据最新版本的手册（第 2 卷），这是保留的编码。其他位指定一个 TLB，它是 16 路完全关联的，并且能够缓存所有页面大小的翻译。 Intel 在优化手册的表 2-5 中提供了有关 Ice Lake 中 TLB 的信息。最接近的匹配表明保留编码 5 最有可能代表用于数据存储转换的第一级 TLB。
[SL 03]：最低有效五位代表数字 4，根据最新版本的手册，这也是保留的编码。与表 2-5 最接近的匹配表明它代表了可以缓存 4KB 转换的数据加载的第一级 TLB。路数和集数与表 2-5 相符。
[SL 04]：类似于 subleaf 0x3。与表 2-5 最接近的匹配表明它代表了用于数据加载的第一级 TLB，可以缓存 2MB 和 4MB 的翻译。路数和集数与表 2-5 相符。
[SL 05]：类似于 subleaf 0x3。与表 2-5 最接近的匹配表明它代表了可以缓存 1GB 转换的数据加载的第一级 TLB。路数和集数与表 2-5 相符。
[SL 06]：描述了由8路128组组成的二级统一TLB，能够缓存4KB、2MB和4MB页面的翻译。
[SL 07]：描述由8路128组组成的二级统一TLB，能够缓存4KB和1GB页面的翻译。

表 2-5 实际上提到了统一的 TLB 结构只有一种，但一半的方式只能缓存 4KB、2MB 和 4MB 页面的翻译，另一半只能缓存 4KB 和 1GB 页面的翻译。所以二级TLB的TLB信息与手册一致。但是，TLB指令的TLB信息与表2-5不一致。手册可能是正确的。在 TLB 信息转储中，4KB 页面的 ITLB 似乎与 2MB 和 4MB 页面的 ITLB 混淆了。

在 AMD 处理器上，第一级和第二级 TLB 的 TLB 信息分别在叶 8000_0005 和 8000_0006 中提供。更多信息可以在 AMD 手册第 3 卷中找到。早于 K5 的 AMD 处理器不支持cpuid，其中一些处理器包括单级 TLB。因此，如果您关心这些处理器，则需要一种替代机制来确定 TLB 是否存在。 Zen 2 在两个 TLB 级别都增加了 1GB 支持。有关这些 TLB 的信息可以在叶子 8000_0019 中找到。

AMD Zen 具有三级指令 TLB 层次结构according to AMD。这是我所知道的第一个使用三层 TLB 层次结构的核心微架构。 AMD Zen+ 和 AMD Zen 2 很可能也是这种情况（但我找不到证实这一点的 AMD 消息来源）。 L0 ITLB 上似乎没有记录在案的cpuid 信息。因此，您可能必须检查处理器是 AMD Zen 还是更高版本，并为这些处理器手动提供 L0 ITLB 信息（所有页面大小的 8 个条目，可能是完全关联的）。

这里的“4-way associative”只是一个错字，意思是“4-way set 联想”？

这不是错字。这些术语是同义词，并且都是常用的。

DTLB 代表数据 TLB 吗？ uTLB 是什么意思？ uosp-TLB？哪个 TLB 这里考虑缓存级别？

DTLB 和 uTLB 都是数据 TLB 的名称。 DTLB 名称用于一级和二级TLB。 uTLB名称仅用于一级数据TLB，是micro-TLB的简称。

这是否意味着在这种情况下，第 2 级 TLB 在所有核心？所以当没有明确指定是TLB缓存核心私人的？

这里的“共享”一词意味着“统一”，因为数据和指令的翻译都可以被缓存。英特尔应该将其称为 UTLB（大写 U）或 Unified TLB，这是现代叶子 0x18 中使用的名称。

【讨论】：

TLB 编号较多的描述符是二级TLB 的描述符 我在0x02leaf 的文档中没有注意到这样的事情。它是否记录在其他地方？
@St.Antario 不。但是对于 4KB 页面来说，二级缓存比一级缓存具有更多条目是很自然的。这在所有当前的 Intel 和 AMD x86 处理器上都是如此，并且将来可能会继续如此。这是确定第二级 TLB 的描述符的一种简单、快速且正确的方法。另一方面，cpuid 工具实际上无法区分叶子 0x02 中的第一级和第二级 TLB。它只会按原样打印手册中表 3-12 中显示的描述。一些编码被明确描述为2nd-Level TLB...
...但我在回答中展示了第二个 TLB 可能被称为其他名称的示例。顺便说一句，在叶子 0x18 中，第一级和第二级 TLB 的编码是不同的，所以没有必要求助于这样的 hack。这是叶子 0x18 的优点之一。以后如果增加了3级TLB，很可能会用0x18的新编码来描述。

【解决方案2】：

将我的 cmets 收集到一个答案中。 Hadi 的回答更直接地回答了更多问题，但希望这是有关 TLB 的有用背景，可帮助您了解它为何如此设计以及它的含义。

您可以查找已知的微架构详细信息，以帮助检查您对cpuid 结果的解释。例如，https://www.7-cpu.com/cpu/Skylake.html 和 https://www.realworldtech.com/haswell-cpu/5/ 有关于这些 Intel uarches 的详细信息。其他来源包括英特尔的优化手册，也许还有 Agner Fog 的微架构指南。 IDK 为什么有些人说“设置”关联而其他人没有；这对 AFAIK 来说并不重要。

（在某些情况下，应用常识推理来判断什么是合理的设计。令人惊讶的结果可能是正确的，但需要更多检查。）

是不是说TLB只有2级？

是的，主流 x86 CPU 仍然“仅”使用 2 级 TLB，而第 2 级是统一的（指令/数据转换）。

第一层被拆分为 L1iTLB（紧密耦合到前端提取阶段）和 L1dTLB（紧密耦合到加载/存储单元）。二级TLB正在统一。

在当前的 Intel CPU 上，L2TLB 基本上是受害者缓存； page walker 结果仅添加到需要它的 L1 TLB，仅在从 L1iTLB 或 L1dTLB 逐出后移动到 L2TLB。我忘记了它们是否是专有的（即交换条目以确保没有重复），但我不这么认为。无论如何，有趣的事实：将代码和数据保持在同一页面中仍然可以触发代码和数据的单独页面遍历，因为代码的 iTLB 未命中不会将结果放在 dTLB 未命中可以看到的任何地方，而不是立即.至少页表数据本身将在 L1d 缓存中，如果访问时间很接近，页面遍历器可以快速获取它。

这是否意味着在这种情况下第二级 TLB 在所有内核之间共享？那么当没有明确指定时，TLB 缓存核心是私有的吗？

TLB 始终是每个核心私有的，即使您愿意，在设计共享条目的方式时也存在重大问题。

与内存内容不同，翻译和invlpg 失效是每个核心私有的。每个逻辑核心都有自己的指向顶级页面目录的 CR3 指针。 有时多个核心正在运行同一进程的线程，因此它们具有相同的 CR3，但有时不。跨内核共享 TLB 的价值有限，除非 x86 ISA 系统编程细节通过跨内核全局的 PTE 概念进行扩展，而不仅仅是跨内核上的 CR3 更改。（那些跨 CR3 更改条目用于始终保持内核虚拟地址空间映射的内核，但语义是根据每个内核的行为而不是真正的全局定义的。） IIRC，PCID（进程上下文 ID）的东西也假设 ID 是每个核心私有的，因此即使这样也无助于启用共享。请注意，启用 Meltdown 缓解后，进入内核确实会更改页表，因此即使是常见的现实用例也不理想。

因此，无论如何，根据现有的 ISA 规则标记共享 TLB 条目以保持正确性存在大量潜在的复杂性。启用超线程后，Sandybridge 甚至可以在逻辑内核之间静态划分小页面 L1iTLB，并复制大页面 L1iTLB (Kanter, RealWorldTech)。

此外，这不是提高性能的最佳方式。脱离核心到共享资源往往很慢；例如L3 数据缓存访问是多个周期。 TLB 条目可以从页表数据重建，该页表数据本身可以被 L3 数据缓存缓存。（也可以通过私有 L2 和 L1d 缓存；Hardware page-walk fetches through the data caches on PPro and later（有趣的事实：与绕过的 P5 Pentium 不同）它的片上缓存））。

与其去核外（延迟大概类似于 L3 缓存）来检查假设的共享 L3TLB（可能仍然会丢失），使用本地页面重建 TLB 条目更有意义- walk 硬件。 Skylake 添加了第二个 HW page-walker，它可以并行处理两个 TLB 未命中（或推测性填充）；这可能比共享 L3TLB 更有帮助，即使在所有内核运行具有大量共享工作集的同一进程的线程的最佳情况下也是如此。如果页表数据必须来自内核外，则将页表中的数据处理成 TLB 条目可能只是总周期的一小部分。

缓存页表数据（如更高级别的页面目录条目）在页面遍历器也有帮助，我认为在实践中已经完成。因此，page-walk 可能只需要获取底部 2 层，例如通过数据缓存。

TL:DR：从现有私有 + 共享数据缓存中快速读取页面遍历硬件，以及推测性 TLB 预取，解决了共享 TLB 可能遇到的相同问题，并有助于提高单独进程情况下的性能。也避免了许多问题。

与共享 L3TLB 相比，添加更多/甚至更好的 page-walk 硬件可以帮助更多案例。

DTLB 代表数据 TLB 吗？ uTLB 是什么意思？优步-TLB？这里考虑哪个 TLB 缓存级别？

是的，DTLB = 数据 TLB。

uTLB 不能用于 uop 缓存；在 Intel CPU 上，uop 缓存实际上是被寻址的，因此它不需要 TLB。（不确定 Ryzen 的 uop-cache 有什么作用，但您正在查看 Intel 文档）。

从大小和其他方面，我们可以看出它也不是统一的 L2TLB。（尽管从 Hadi 的回答来看，似乎 UTLB 在某些情况下可能意味着统一，即组合或共享数据和指令）

我发现https://software.intel.com/en-us/vtune-amplifier-help-utlb-overhead 似乎并不是说 UTLB = 一级数据 TLB。也许它的意思是“微型 TLB”，就像只有几个条目的小型/快速 TLB，与更大的 L2TLB 相比。

Hadi 发现在某些 Silvermont 系列 CPU 上，“uTLB”适用于 4k 页面，而 DTLB 则适用于其他页面大小。看起来“微型 TLB”是正确的解释方式。

我还找到了关于 TLB 的 https://wikichip.org/wiki/intel/microarchitectures/kaby_lake 资源。有一个注意事项：STLB 被 CPUID 叶 2 (EAX=02H) 错误地报告为“6 路”。 Kaby Lake 勘误表 KBL096 建议软件简单地忽略该值。这实际上是 12 路关联。 cpuid 所有 Kaby Lake cpus 的错误？

是的，CPU通过CPUID报错信息是CPU的bug；这就是为什么 KBL096 是 CPU 错误，而不是使用 cpuid 的软件中的错误。

如果此类软件遵循正常规则，它会得到与 KBL 实际拥有的结果不匹配的结果。英特尔建议软件对此进行特殊处理，并简单地打印已知的正确结果，而不是 cpuid 数据所指示的内容。

【讨论】：

手册说寄存器 EAX（寄存器 AL）中的最低有效字节将始终返回 01H。软件应忽略此值，而不是将其解释为信息描述符。，但下一个项目符号是 每个寄存器的最高有效位（位 31）指示寄存器是否包含有效信息（设置为 0 ) 或保留（设置为 1）。 你能想象将EAX LSB 设为例外情况有什么意义吗？我想这是出于历史原因，所以我只需将 EAX LSB 归零并将其作为所有其他寄存器处理。
你能解释一下data TLB和instruction TLB有什么区别
@zerocool：iTLB 用于指令获取，dTLB 用于数据加载/存储执行单元。因此名称。另见Is TLB used at all in the instruction fetching pipeline 和VIPT Cache: Connection between TLB & Cache?。特别注意 L1iTLB 在 realworldtech.com/haswell-cpu/2 中与 L1dTLB 在 realworldtech.com/haswell-cpu/5 中的位置
@PeterCordes 那么我们是否可以认为 iTLB 是从我们缓存的页面中获取代码时，而 dTLB 是在我们从已缓存的页面中获取数据时？
@zerocool：关闭，但缓存翻译（页表条目）与缓存内容是分开的。无论您是否在 L1d 缓存中命中，您总是需要 dTLB 进行代码提取以将虚拟转换为物理。也许你一开始就不知道 TLB 是什么？ en.wikipedia.org/wiki/Translation_lookaside_buffer 是谷歌上“TLB”（对我来说）的第一次点击。