操作系统MIT6.S081：P3-＞Page tables

本系列文章为MIT6.S081的学习笔记，包含了参考手册、课程、实验三部分的内容，前面的系列文章链接如下
操作系统MIT6.S081：[xv6参考手册第1章]->操作系统接口
操作系统MIT6.S081：P1->Introduction and examples
操作系统MIT6.S081：Lab1->Unix utilities
操作系统MIT6.S081：[xv6参考手册第2章]->操作系统组织结构
操作系统MIT6.S081：P2->OS organization and system calls
操作系统MIT6.S081：Lab2->System calls
操作系统MIT6.S081：[xv6参考手册第3章]-＞页表

---

一、前言

今天课程的主题是虚拟内存(Virtual Memory)。具体来说，我们会介绍页表(page tables)。在后面的课程中，我们还会介绍虚拟内存相关的其他内容。首先，我们会从一些问答开始今天的课程。

问答

Frans教授：我先来说一下我自己对于虚拟内存或者页表的认知。当我还是个学生并第一次听到这个词时，我认为它还是很简单的。无非就是张表，将虚拟地址和物理地址映射起来。实际可能稍微复杂一点，但是应该不会太难。可是当我开始写代码实现虚拟内存时，我才知道虚拟内存比较棘手、有趣，功能也很强大。所以，希望在接下来的几节课和几个实验中，你们也会虚拟内存有相同的理解。接下来我会问你们对于虚拟内存的一些理解。
学生回答：它使用偏移量来保存虚拟内存到物理内存的映射关系。
学生回答：这是用来保护硬件设备的。在6.004中介绍的，虚拟地址是44bit，最终会映射到某些64bit的物理地址。
学生回答：通过虚拟内存，每个进程都可以有独立的地址空间。通过地址管理单元(MMU, Memory Management Unit) 或者其他的技术，可以将每个进程的虚拟地址空间映射到物理内存地址。虚拟地址的低bit相同，所以映射是以块为单位进行，同时性能也很好。
学生回答：虚拟地址可以保护进程的物理地址。通过一些巧妙的操控，我们可以实现读写虚拟地址最后实际读写物理地址。
学生回答：虚拟内存对于隔离性来说是非常基础的，每个进程都可以认为自己有独立的内存可以使用。
Frans教授：刚刚的回答中，很明显有两件事情是对的。这里存在某种形式的映射关系，并且映射关系对于实现隔离性来说有帮助。

课程内容

隔离性是我们讨论虚拟内存的主要原因。在接下来的两节课，尤其当我们开始通过代码实现虚拟内存之后，我们可以真正理解它的作用。这节课我们主要关注虚拟内存的工作机制，之后我们会看到如何使用这里的机制来实现非常酷的功能。
今天天的内容主要是3个部分：
①首先我会讨论一下地址空间(Address Spaces)，这个在刚刚的问答中有的同学也提到了。
②接下来我会谈一下支持虚拟内存的硬件(Paging hardware)。当然，我介绍的是RISC-V相关的硬件。但是从根本上来说，所有的现代处理器都有某种形式的页式硬件，来作为实现虚拟内存的默认机制。
③最后，我们会看一下XV6中的虚拟内存代码，并看一下内核地址空间和用户地址空间的结构。

二、地址空间

强隔离性

在最开始的回答中，很多同学都提到了，创造虚拟内存的一个出发点是你可以通过它实现隔离性。如果你正确地设置了页表，并且通过代码对它进行正确的实现，那么原则上你可以实现强隔离。所以，我们先来回顾一下，我们期望从隔离性中得到什么样的效果。在下面这个经常出现的图中，我们有一些用户应用程序(如Shell、cat、在lab1创造的各种工具)。在这些应用程序下面是内核，操作系统位于内核空间。

对于隔离性，我们期望的是：每个用户程序都被装进一个盒子里，这样它们就不会彼此影响了。类似的，我们也想让它们与内核操作系统相互独立，这样如果某个应用程序无意或者故意做了一些坏事，也不会影响到操作系统。

面临问题

今天的课程中，我们想关注的是内存的隔离性。如果我们不做任何工作，默认情况下我们是没有内存隔离性的。你们可以回想一下，在我们上节课展示的RISC-V主板上，内存是由一些DRAM芯片组成。在这些DRAM芯片中保存了程序的数据和代码。例如内存中的某一个部分是内核，包括了文本、数据、栈等。如果运行了Shell，内存中的某个部分就是Shell。如果运行了cat程序，内存中的某个部分是cat程序。这里说的都是物理内存，它的地址从0开始到某个很大的地址结束，结束地址取决于我们的机器现在究竟有多少物理内存。所有程序都必须存在位于物理内存中，否则处理器甚至都不能处理程序的指令。

这里的风险很明显。我们简单化一下场景，假设Shell存在于内存地址1000-2000之间。

如果cat出现了程序错误，将内存地址1000(也就是Shell的起始地址)加载到寄存器a0中。之后执行sd $7, (a0)，这里等效于将7写入内存地址1000。

现在cat程序弄乱了Shell程序的内存镜像，所以隔离性被破坏了，这是我们不想看到的现象。所以，我们想要某种机制，能够将不同程序之间的内存隔离开来，这样类似的事情就不会发生。

地址空间

一种实现方式是地址空间(Address Spaces)。这里的基本概念简单直观，我们给包括内核在内的所有程序专属的地址空间。例如，当我们运行cat时，它的地址空间从0到某个地址结束。当我们运行Shell时，它的地址也从0开始到某个地址结束。内核的地址空间也从0开始到某个地址结束。

如果cat程序想要向地址1000写入数据，那么cat只会向它自己的地址1000，而不是Shell的地址1000写入数据。所以，基本上来说，每个程序都运行在自己的地址空间，并且这些地址空间彼此之间相互独立。在这种不同地址空间的概念中，cat程序甚至都不能访问属于Shell的内存地址。这是我们想要达成的终极目标，因为这种方式为我们提供了强隔离性，cat现在不能访问任何不属于自己的内存。
接下来的问题： 现在我们的问题是如何在一个物理内存上，复用不同的地址空间。因为归根到底，我们使用的还是一堆存放了内存信息的DRAM芯片。

问答

学生提问：我比较好奇物理内存的配置。因为物理内存的数量是有限的，而虚拟地址空间存在最大虚拟内存地址。由于会有很多个虚拟地址空间，所以我们在设计的时候需要将最大虚拟内存地址设置的足够小吗？
Frans教授：并不必要，虚拟内存可以比物理内存更大，物理内存也可以比虚拟内存更大。我们马上就会看到这里是如何实现的，其实就是通过页表来实现，这里非常灵活。
学生提问：如果有太多的进程使用了虚拟内存，有没有可能物理内存耗尽了？
Frans教授：这必然是有可能的。我们接下来会看到如果你有一些大的应用程序，每个程序都有大的页表，并且分配了大量的内存，在某个时间你的内存就耗尽了。
Frans教授：在XV6中从哪可以看到内存耗尽了？如果你们完成了syscall实验，你们会知道在syscall实验中有一部分是打印剩余内存的数量。
学生回答：kalloc
Frans教授：是的，kalloc保存了空余页表的列表。如果这个列表为空，那么kalloc会返回一个空指针。内核会妥善处理并将结果返回给用户应用程序，并告诉用户应用程序要么是对这个应用程序没有额外的内存了，要么是整个机器都没有内存了。内核的一部分工作就是优雅地处理这些情况，这里的优雅是指向用户应用程序返回一个错误消息，而不是直接崩溃。

三、页表

3.1 页表的基本概念

页表的基本概念

问题： 我们如何能够实现地址空间呢？或者说如何在一个物理内存上复用所有的地址空间？
回答： 最常见同时也是非常灵活的一种方法就是使用页表(Page Tables)。页表在硬件中通过处理器和内存管理单元实现。所以，在你们的脑海中，应该有这么一张图：CPU正在执行指令，例如sd $7, (a0)。

当CPU执行存储指令、加载指令等任何一条带有地址的指令，其中的地址应该认为是虚拟内存地址而不是物理地址。假设寄存器a0中是地址0x1000，那么这是一个虚拟内存地址。这个虚拟内存地址会被发送内存管理单元MMU。

内存管理单元会将这个虚拟地址翻译成物理地址。之后这个物理地址会被用来索引物理内存，并从物理内存加载或存储数据。

从CPU的角度来说，一旦MMU打开了，它执行的每条指令中的地址都是虚拟内存地址。为了能够完成虚拟内存地址到物理内存地址的转换，MMU会有一张表。表的一边是虚拟内存地址，另一边是物理内存地址。举个例子，虚拟内存地址0x1000对应了一个物理内存地址0xFFF0(随口说的一个地址)。

通常来说，这个映射表也保存在内存中，所以CPU中需要有一些寄存器用来存放这张表在物理内存中的地址。现在，内存的某个位置保存了地址映射表，我们假设这个位置的物理内存地址是0x10。在RISC-V上一个叫做SATP的寄存器会保存地址0x10。这样，CPU就可以告诉MMU可以从哪找到将虚拟内存地址映射成物理内存地址的表。

问答

学生提问：所以MMU并不会保存页表，它只会从内存中读取页表然后完成翻译是吗？
Frans教授：是的，这就是你们应该记住的。页表保存在内存中，MMU只是会去查看页表，我们接下来会看到页表比我们这里画的要稍微复杂一些。这里的基本想法是每个应用程序都有自己独立的映射表，这个映射表定义了应用程序的地址空间。所以当操作系统将CPU从一个应用程序切换到另一个应用程序时，同时也需要切换SATP寄存器中的内容，从而指向新的进程保存在物理内存中的地址映射表。这样的话，cat程序和Shell程序中相同的虚拟内存地址就可以翻译到不同的物理内存地址，因为每个应用程序都有属于自己的不同的地址映射表。
学生提问：刚刚说到SATP寄存器会根据进程而修改，我猜每个进程对应的SATP值是由内核保存的？
Frans教授：是的，写SATP寄存器是一条特殊权限指令。所以，用户应用程序不能通过更新这个寄存器来更换一个地址映射表，否则的话就会破坏隔离性。只有运行在kernel mode的代码可以更新这个寄存器。

3.2 页表的工作原理

问题引出

问题： 从前面画的图看来，对于每个虚拟地址，在映射表中都有一个对应的地址。如果我们真的这么做，这张映射表会有多大？寄存器是64bit的，所以有 $2^{64}$ 个地址。这张表非常大，仅包含这张表就会使用掉所有的内存，所以这一点也不合理。所以，实际情况不可能是一个虚拟内存地址对应页表中的一个条目。接下来我将分两步介绍RISC-V中是如何工作的。

①第一步：

不要为每个地址创建一个表单条目，而是为每一个page创建一条表单条目，所以每一次地址翻译都是针对一个page。在RISC-V中，一个page是4KB，也就是4096Bytes。这个大小非常常见，几乎所有的处理器都使用4KB大小的page或者支持4KB大小的page。现在，内存地址的翻译方式略微有些不同了。首先对于虚拟内存地址，我们将它划分为两个部分，索引(index)和偏移量(offset)，index用来查找page，offset对应的是一个page中的哪个字节。

所以当MMU在做地址翻译的时候，通过读取虚拟内存地址中的index可以知道物理内存中的page号，这个page号对应了物理内存中的4096个字节。之后虚拟内存地址中的offset指向了page中的4096个字节中的某一个，假设offset是12，那么page中的第12个字节被使用了。将offset加上page的起始地址，就可以得到物理内存地址。

有关RISC-V的一件有意思的事情是：虚拟内存地址都是64bit，因为RISC-V的寄存器是64bit的。但是实际上，在我们使用的RSIC-V处理器上，并不是所有的64bit都被使用了，其中高25bit没有被使用。这样的结果是限制了虚拟内存地址的数量，虚拟内存地址的数量现在只有 $2^{39}$ 个，大概是512GB。当然，如果必要的话，最新的处理器或许可以支持更大的地址空间，只需要将未使用的25bit拿出来做为虚拟内存地址的一部分即可。在剩下的39bit中，有27bit被用来当做index，12bit被用来当做offset。offset必须是12bit，因为对应了一个page的4096个字节。

在RISC-V中，物理内存地址是56bit，所以物理内存可以大于单个虚拟内存地址空间。56bit的物理内存中，44bit是物理page号(PPN, Physical Page Number)，剩下12bit是offset，从虚拟内存地址继承而来。(也就是说，做地址转换时，只需要将虚拟内存中的27bit翻译成物理内存中的44bit的page号，剩下12bit的offset直接拷贝过来即可)。

问答：

学生提问：我想知道4096字节作为一个page，这在物理内存中是连续的吗？
Frans教授：是的，在物理内存中这是连续的4096个字节，所以物理内存是以4096为单位使用的。
学生提问：所以offset才是12bit，这样就足够覆盖4096个字节？
Frans教授：是的，page中的每个字节都可以被offset索引到。
学生提问：图中的56bit又是根据什么确定的？
Frans教授：这是由硬件设计人员决定的，RISC-V的设计人员认为56bit的物理内存地址是个不错的选择。可以假定他们是通过技术发展的趋势得到这里的数字。比如说，设计是为了满足5年的需求，可以预测物理内存在5年内不可能超过 $2^{56}$ 这么大。或者他们预测是的一个小得多的数字，但是为了防止预测错误，他们选择了像 $2^{56}$ 这么大的数字。
学生提问：如果虚拟内存最多是 $2^{39}$，而物理内存最多是 $2^{56}$，这样我们可以有多个进程都用光了他们的虚拟内存，但是物理内存还有剩余，对吗？
Frans教授：是的，完全正确。
学生提问：这是一个64bit的机器，为什么硬件设计人员本可以用64bit但是却用了56bit？
Frans教授：选择56bit而不是64bit是因为在主板上只需要56根线。
学生提问：我们从CPU到MMU之后到了内存，但是不同的进程之间的虚拟地址怎么区别？比如说Shell进程在地址0x1000存了一些数据，ls进程也在地址0x1000也存了一些数据，我们需要怎么将它们翻译成不同的物理内存地址。
Frans教授：SATP寄存器包含了需要使用的地址转换表的内存地址。所以ls有自己的地址转换表，cat也有自己的地址转换表，每个进程都有完全属于自己的地址转换表。

②第二步：

通过前面的第一步，我们知道地址转换表是以page为单位，而不是以单个内存地址为单位。现在这个地址转换表已经可以被称为页表了，但是还不能满足实际的需求。如果每个进程都有自己的页表，那么每个页表会有多大呢？

这个页表最多会有 $2^{27}$ 个条目(虚拟内存地址中的index长度为27)，这是个非常大的数字。如果每个进程都使用这么大的页表，则进程需要为页表消耗大量的内存，并且物理内存很快就会耗尽。所以实际上，硬件并不是按照这里的方式来存储页表。从概念上来说，你可以认为页表是从 $0$ 到 $2^{27}$，但是实际上并不是这样。实际中，页表是一个多级的结构。下图是一个真正的RISC-V页表结构和硬件实现。

我们之前提到的虚拟内存地址中的27bit的index，实际上是由3个9bit的数字组成(L2，L1，L0)。最开始的9个bit(L2)被用来索引最高级的页表目录(Page Directory)。(注：通常page directory是用来索引页表或者其他page directory物理地址的表单，但是在课程中，page table，page directory， page directory table区分并不明显，可以都认为是有相同结构的地址对应表单)。

一个Page Directory是4096Bytes，就跟page的大小是一样的。Page Directory中的一个条目被称为PTE(Page Table Entry)，是64bits(和寄存器的大小一样，就是8Bytes)。所以一个page directory有 $4096/8=512$ 个条目。

所以实际上，SATP寄存器会指向最高一级的page directory的物理内存地址，之后我们用虚拟内存中index的高9bit用来索引最高一级的page directory，这样我们就能得到一个物理页号(PPN, physical page number)。这个PPN指向了中间级的page directory。当我们在使用中间级的page directory时，我们通过虚拟内存地址中的L1部分完成索引。接下来会走到最低级的page directory，我们通过虚拟内存地址中的L0部分完成索引。在最低级的page directory中，我们可以得到对应于虚拟内存地址的物理内存地址。

从某种程度上来说，与之前一种方案还是很相似的，除了实际的索引是由3步，而不是1步完成。这种方式的主要优点是，如果地址空间中大部分地址都没有使用，你不必为每一个index准备一个条目。举个例子，如果你的地址空间只使用了一个page，4096Bytes。

现在，你需要多少个PTE或者page table directory来映射这一个page？在最高级，你需要一个page directory。在这个page directory中，你需要一个数字是0的PTE，指向中间级page directory。所以在中间级，你也需要一个page directory，里面也是一个数字0的PTE，指向最低级page directory。所以这里总共需要3个page directory(也就是 $3\ast 512=1536$ 个条目)。

而在前一个方案中，虽然我们只使用了一个page，还是需要 $2^{27}$ 个PTE。这个方案中，我们只需要 $3\ast 512$ 个PTE，所需的空间大大减少了。这也是硬件在实际中采用这种层次化的3级page directory结构的主要原因。

问答

学生提问：既然每个物理page的PPN是44bit，而物理地址是56bit，我们从哪得到缺失的12bit？
Frans教授：所有的page directory传递的都是PPN，对应的物理地址是44bit的PPN加上12bit的0。如果我们查看这里的PTE条目，它们都有相同的格式，其中44bit是PPN，但是寄存器是64bit的，所有有一些bit是留空的。实际上，支持page的硬件在低10bit存了一些标志位用来控制地址权限。

如果你把44bit的PPN和10bit的Flags相加是54bit，也就是说还有10bit未被使用，这10bit被用来作为未来扩展。比如说某一天你有了一个新的RISC-V处理器，它的页表可能略有不同，或许有超过44bit的PPN。根据下面这张图你可以看到，这里有10bit是作为保留字段存在的。

3.3 PTE与TLB

PTE的结构

每个PTE的低10bit是一堆标志位：
①第一个标志位是Valid。如果Valid位为1，那么表明这是一条合法的PTE，你可以用它来做地址翻译。对于刚刚举的那个例子(应用程序只用了1个page)，我们只使用了3个page directory，每个page directory中只有第0个PTE被使用了，所以只有第0个PTE的Valid bit位会被设置成1，其他的511个PTE的Valid bit为0。这个标志位告诉MMU，你不能使用这条PTE，因为这条PTE并不包含有用的信息。
②下两个标志位分别是Readable和Writable，表明你是否可以读/写这个page。
③Executable表明你可以从这个page执行指令。
④User表明这个page可以被运行在用户空间的进程访问。
⑤其他标志位并不是那么重要，它们偶尔会出现，前面5个是重要的标志位。

问答

学生提问：我对于这里的3级页表结构有个问题，PPN是如何合并成最终的物理内存地址？
Frans教授：我之前或许没有很直接的说这部分。在最高级的page directory中的PPN，包含了下一级page directory的物理内存地址，依次类推。在最低级page directory，我们还是可以得到44bit的PPN，这里包含了我们实际上想要映射的物理page地址，然后再加上虚拟内存地址的12bit offset，就得到了56bit物理内存地址。
Frans教授：让我来问一个有趣的问题，为什么page directory中保存的是物理页面编号，而不是虚拟内存地址？
学生回答：因为我们需要在物理内存中查找下一个page directory的地址。
Frans教授：是的，我们不能让我们的地址转换依赖于另一种转换，否则我们可能会陷入递归的无限循环中。所以page directory必须存物理地址。那SATP呢？它存的是物理地址还是虚拟地址？
学生回答：还是物理地址，因为最高级的page directory还是存在物理内存中。
Frans教授：是的，这里必须是物理地址，因为我们要用它来完成地址映射，而不是对它进行地址映射。所以SATP需要知道最高一级的page directory的物理地址是什么。
学生提问： 这里有层次化的3个页表，每个页表都由虚拟地址的9个bit来索引，所以是由虚拟地址中的3个9bit来分别索引3个页表，对吗？
Frans教授：是的，最高的9个bit用来索引最高一级的page directory，第二个9bit用来索引中间级的page directory，第三个9bit用来索引最低级的page directory。
学生提问： 当一个进程请求一个虚拟内存地址时，CPU会查看SATP寄存器得到对应的最高一级页表，这级页表会使用虚拟内存地址中27bit index的最高9bit来完成索引，如果索引的结果为空，MMU会自动创建一个页表吗？
Frans教授：不会的，MMU会告诉操作系统或者处理器不能翻译这个地址，最终这会变成一个page fault。如果一个地址不能被翻译，那就不翻译。就像你在运算时除以0一样，处理器会拒绝那样做。
学生提问： 我想知道我们是怎么计算页表的物理地址，是不是这样，我们从最高级的页表得到44bit的PPN，然后再加上虚拟地址中的12bit offset，就得到了完整的56bit 页表物理地址？
Frans教授：我们不会加上虚拟地址中的offset，这里只是使用了12bit的0。所以我们用44bit的PPN，再加上12bit的0，这样就得到了下一级page directory的56bit物理地址。这里要求每个page directory都与物理page对齐(也就是page directory的起始地址就是某个page的起始地址，所以低12bit都为0)。

TLB

TLB来源： 如果我们回想一下页表的结构，你可以发现：当处理器从内存加载或存储数据时，基本上都要做3次内存查找。第一次在最高级的page directory，第二次在中间级的page directory，最后一次在最低级的page directory。所以对于一个虚拟地址的寻址，需要读三次内存，代价有点高。所以实际中，几乎所有的处理器都会对最近使用过的虚拟地址的映射结果有缓存，这个缓存被称为：页表缓存(Translation Lookside Buffer, TLB)。基本上来说，这就是Page Table Entry(PTE)的缓存。
TLB的工作原理： 当处理器第一次查找一个虚拟地址时，硬件通过3级页表结构得到最终的PPN，TLB会保存虚拟地址到物理地址的映射关系。这样下一次当你访问同一个虚拟地址时，处理器可以查看TLB，TLB会直接返回物理地址，而不需要通过页表得到结果。

问答

学生提问：前面说TLB会保存虚拟地址到物理地址的对应关系，如果在page级别做cache是不是更加高效？
Frans教授：有很多种方法都可以实现TLB，对于你们来说最重要的是知道TLB是存在的。TLB实现的具体细节不是我们要深入讨论的内容。这是处理器中的一些逻辑，对于操作系统来说是不可见的，操作系统也不需要知道TLB是如何工作的。你们需要知道TLB存在的唯一原因是，如果你切换了页表，操作系统需要告诉处理器当前正在切换页表，处理器会清空TLB。因为本质上来说，如果你切换了页表，TLB中的缓存将不再有用，它们需要被清空，否则地址翻译可能会出错。所以操作系统知道TLB是存在的，但只会时不时的告诉操作系统，现在的TLB不能用了，因为要切换页表了。在RISC-V中，刷新TLB的指令是sfence_vma。

学生提问：3级的页表是由操作系统实现的还是由硬件自己实现的？
Frans教授：这是由硬件实现的，所以3级页表的查找都发生在硬件中。MMU是硬件的一部分而不是操作系统的一部分。在XV6中，有一个函数也实现了页表的查找，因为时不时的XV6也需要完成硬件的工作。所以XV6中有个叫做walk的函数，它在软件中实现了MMU硬件相同的功能。
学生提问：在这个机制中，TLB发生在哪一步，是在地址映射之前还是之后？
Frans教授：整个CPU和MMU都在处理器芯片中，所以在一个RISC-V芯片中，有多个CPU核，MMU和TLB存在于每一个CPU核里面。RISC-V处理器有L1 cache，L2 Cache，有些cache是根据物理地址索引的，有些cache是根据虚拟地址索引的，由虚拟地址索引的cache位于MMU之前，由物理地址索引的cache位于MMU之后。
学生提问：之前提到，硬件会完成3级页表的查找，那为什么我们要在XV6中有一个walk函数来完成同样的工作？
Frans教授：这里有几个原因，首先XV6中的walk函数设置了最初的页表，它需要对3级页表进行编程，所以它首先需要能模拟3级页表。另一个原因或许你们已经在syscall实验中遇到了，在XV6中，内核有它自己的页表，用户进程也有自己的页表。用户进程指向sys_info结构体的指针存在于用户空间的页表，但是内核需要将这个指针翻译成一个自己可以读写的物理地址。如果你查看copy_in，copy_out，你可以发现内核会通过用户进程的页表，将用户的虚拟地址翻译得到物理地址，这样内核可以读写相应的物理内存地址。这就是为什么在XV6中需要有walk函数的一些原因。
学生提问：为什么硬件不开发类似于walk函数的接口？这样我们就不用在XV6中用软件实现自己的接口，自己实现还容易有bug。为什么没有一个特殊权限指令，接收虚拟内存地址，并返回物理内存地址？
Frans教授：其实这就跟你向一个虚拟内存地址写数据，硬件会自动帮你完成翻译物理地址、数据写入一样。你们在页表实验中会完成相同的工作，你们要以不同的方式设置页表，让你们可以在copyin和copyinstr中避免walk。我们接下来在看XV6的实现的时候会看到更多的内容。

page fault

在介绍XV6的页表之前，有关页表我还想说一点。用时髦的话说，页表提供了一层抽象(level of indirection)。我这里说的抽象就是指从虚拟地址到物理地址的映射，这里的映射关系完全由操作系统控制。

因为操作系统对于这里的地址翻译有完全的控制，它可以实现各种各样的功能。比如，当一个PTE是无效的，硬件会返回一个page fault。对于这个page fault，操作系统可以更新页表并再次尝试指令。所以，通过操纵页表，在运行时有各种各样可以做的事情。我们在之后有一节课专门会讲，当出现page fault的时候，操作系统可以做哪些有意思的事情。现在只需要记住，页表是一个无比强大的机制，它为操作系统提供了非常大的灵活性。这就是为什么页表如此流行的一个原因。

四、xv6中的页表

XV6的Kernel Page的分布

接下来我们看一下在XV6中页表是如何工作的，首先我们来看一下kernel page的分布。下图就是内核中地址的对应关系，左边是内核的虚拟地址空间，右边上半部分是物理内存(DRAM)，右边下半部分是I/O设备。接下来我会首先介绍右半部分，然后再介绍左半部分。

图中的右半部分的结构完全由硬件设计者决定。如你们上节课看到的一样，当操作系统启动时，会从地址0x80000000开始运行，这个地址其实也是由硬件设计者决定的。具体的来说，如果你们看一个主板：

中间是RISC-V处理器，有4个核，每个核都有自己的MMU和TLB。处理器旁边就是DRAM芯片。

主板的设计人员决定了，在完成了虚拟到物理地址的翻译之后，如果得到的物理地址大于0x80000000会走向DRAM芯片，如果得到的物理地址低于0x80000000会指向不同的I/O设备。这是由这个主板的设计人员决定的物理结构。如果你想要查看这里的物理结构，你可以阅读主板的手册，手册中会一一介绍物理地址对应关系。


这里展示了电路板的内存映射。首先，地址0是保留的，地址0x10090000对应以太网，地址0x80000000对应DDR内存(处理器外的易失存储Off-Chip Volatile Memory)，也就是主板上的DRAM芯片。所以，在你们的脑海里应该要记住这张主板的图片，即使我们接下来会基于你们都知道的C语言程序—QEMU来做介绍，但是最终所有的事情都是由主板硬件决定的。
问答
学生提问：当你说这里是由硬件决定的，硬件是特指CPU还是说CPU所在的主板？
Frans教授：CPU所在的主板。CPU只是主板的一小部分，DRAM芯片位于处理器之外。是主板设计者将处理器，DRAM和许多I/O设备汇总在一起。对于一个操作系统来说，CPU只是一个部分，I/O设备同样也很重要。所以当你在写一个操作系统时，你需要同时处理CPU和I/O设备，比如你需要向互联网发送一个报文，操作系统需要调用网卡驱动和网卡来实际完成这个工作。
物理地址的分布
可以看到最下面是未被使用的地址，这与主板文档内容是一致的(地址为0)。地址0x1000是boot ROM的物理地址，当你对主板上电，主板做的第一件事情就是运行存储在boot ROM中的代码。当boot完成之后，会跳转到地址0x80000000，操作系统需要确保那个地址有一些数据能够接着启动操作系统。

这里还有一些其他的I/O设备：
PLIC是中断控制器(Platform-Level Interrupt Controller)，我们下周的课会讲。
CLINT(Core Local Interruptor)也是中断的一部分。基本上多个设备都能产生中断，需要中断控制器来将这些中断路由到合适的处理函数。
UART0(Universal Asynchronous Receiver/Transmitter)负责与Console和显示器交互。
VIRTIO disk，与磁盘进行交互。地址0x02000000对应CLINT，当你向这个地址执行读写指令，你是向实现了CLINT的芯片执行读写。这里你可以认为你直接在与设备交互，而不是读写物理内存。
问答
学生提问：我想确认一下，低于0x80000000的物理地址不存在于DRAM中。当我们在使用这些地址的时候，指令会直接走向其他的硬件，对吗？
Frans教授：是的，高于0x80000000的物理地址对应DRAM芯片。对于低于0x80000000的物理地址例如以太网接口，我们可以对这个叫做内存映射I/O(Memory-mapped I/O)的地址执行读写指令，来完成设备的操作。
学生提问：为什么物理地址最上面一大块标为未被使用？
Frans教授：物理地址总共有 $2^{56}$ 那么多，但是你不用在主板上接入那么多的内存。所以有多少物理地址没有被用到取决于主板上有多少DRAM芯片。实际上在XV6中，我们限制了内存的大小是128MB。
学生提问：当读指令从CPU发出后，它是怎么路由到正确的I/O设备的？比如说，当CPU要发出指令时，它可以发现现在地址是低于0x80000000，但是它怎么将指令送到正确的I/O设备？
Frans教授：你可以认为在RISC-V中有一个多路输出选择器(demultiplexer)。
XV6虚拟地址与物理地址的映射关系
接下来我会切换到第一张图的左边，这就是XV6的虚拟内存地址空间。当机器刚刚启动时，还没有可用的page，XV6操作系统会设置好内核使用的虚拟地址空间，也就是这张图左边的地址分布。因为我们想让XV6尽可能的简单易懂，所以这里的虚拟地址到物理地址的映射，大部分是相等的关系。比如说内核会按照这种方式设置页表，虚拟地址0x02000000对应物理地址0x02000000。这意味着左侧低于PHYSTOP的虚拟地址，与右侧使用的物理地址是一样的。所以，这里的箭头都是水平的，因为这里是完全相等的映射。

除此之外，这里还有两件重要的事情：
①有一些page在虚拟内存中的地址很高，比如kernel stack在虚拟内存中的地址就很靠后。
----这是因为在它之下有一个未被映射的Guard page，这个Guard page对应的PTE的Valid 标志位没有设置，这样，如果kernel stack耗尽了，它会溢出到Guard page。因为Guard page的PTE中Valid标志位未设置，会导致立即触发page fault。这样的结果好过内存越界之后造成的数据混乱。立即触发一个panic(也就是page fault)，你就知道kernel stack出错了。同时我们也又不想浪费物理内存给Guard page，所以Guard page不会映射到任何物理内存，它只是占据了虚拟地址空间的一段靠后的地址。
-----同时，kernel stack被映射了两次，在靠后的虚拟地址映射了一次，在PHYSTOP下的Kernel data中又映射了一次，但是实际使用的时候用的是上面的部分，因为有Guard page会更加安全。
----这是众多你可以通过页表实现的有意思的事情之一。你可以向同一个物理地址映射两个虚拟地址、可以不将一个虚拟地址映射到物理地址。可以是一对一的映射、一对多映射、多对一映射。XV6至少在1-2个地方用到类似的技巧。这的kernel stack和Guard page就是XV6基于页表使用的有趣技巧的一个例子，主要用来追踪BUG。

②第二件事情是权限。例如Kernel text page内核文本页映射位R-X，意味着你可以读取它，也可以在这个地址段执行指令，但是你不能向Kernel text写数据。通过设置权限我们可以尽早的发现Bug从而避免Bug。对于Kernel data需要能被写入，所以它的标志位是RW-，但是你不能在这个地址段运行指令，所以它的X标志位未被设置。(注：所以，kernel text用来存代码，代码可以读，可以运行，但是不能篡改。kernel data用来存数据，数据可以读写，但是不能通过数据伪装代码在kernel中运行)

问答

学生提问：不同的进程会有不同的kernel stack吗？
Frans教授：是的，每一个用户进程都有一个对应的kernel stack
学生提问：用户程序的虚拟内存会映射到未使用的物理地址空间吗？
Frans教授：在kernel的虚拟地址空间中，有一段Free Memory，它对应了物理内存中的一段地址。XV6使用这段free memory来存放用户进程的page table，text和data。如果我们运行了非常多的用户进程，某个时间点我们会耗尽这段内存，这个时候fork或者exec会返回错误。

学生提问：这就意味着，用户进程的虚拟地址空间会比内核的虚拟地址空间小的多，是吗？
Frans教授：本质上来说，两边的虚拟地址空间大小是一样的。但是用户进程的虚拟地址空间使用率会更低。
学生提问：如果多个进程都将内存映射到了同一个物理位置，这里会优化合并到同一个地址吗？
Frans教授：XV6不会做这样的事情，但是本章的实验中有一部分就是做这个事情。真正的操作系统会做这样的工作。当你们完成了本章的实验，你们就会对这些内容更加了解。

五、xv6页表的实现代码

接下来，让我们看一看代码，我认为很多东西都会因此变得更加清晰。首先，我们来做一个的常规操作，启动我们的XV6，这里QEMU实现了主板，同时我们打开gdb。

kvminit
上一次我们看了boot的流程，我们跟到了main函数。main函数中调用的一个函数是kvminit(3.9)，这个函数会设置好kernel的地址空间。kvminit的代码如下所示：

/*
 * create a direct-map page table for the kernel.
 */
void
kvminit()
{
  kernel_pagetable = (pagetable_t) kalloc();
  memset(kernel_pagetable, 0, PGSIZE);

  // uart registers
  kvmmap(UART0, UART0, PGSIZE, PTE_R | PTE_W);

  // virtio mmio disk interface
  kvmmap(VIRTIO0, VIRTIO0, PGSIZE, PTE_R | PTE_W);

  // CLINT
  kvmmap(CLINT, CLINT, 0x10000, PTE_R | PTE_W);

  // PLIC
  kvmmap(PLIC, PLIC, 0x400000, PTE_R | PTE_W);

  // map kernel text executable and read-only.
  kvmmap(KERNBASE, KERNBASE, (uint64)etext-KERNBASE, PTE_R | PTE_X);

  // map kernel data and the physical RAM we'll make use of.
  kvmmap((uint64)etext, (uint64)etext, PHYSTOP-(uint64)etext, PTE_R | PTE_W);

  // map the trampoline for trap entry/exit to
  // the highest virtual address in the kernel.
  kvmmap(TRAMPOLINE, (uint64)trampoline, PGSIZE, PTE_R | PTE_X);
}

我们在前一部分看了kernel的地址空间长成什么样，这里我们来看一下代码是如何将它设置好的。首先在kvminit中设置一个断点，之后运行代码到断点位置。在gdb中执行layout split，可以看到函数的第一步是为最高一级page directory分配物理page(调用kalloc就是分配物理page)。下一行将这段内存初始化为0，所有PTE都是0。

之后，通过kvmmap函数，将每一个I/O设备映射到内核。例如，下图中高亮的行将UART0映射到内核的地址空间。

我们可以查看一个文件叫做memlayout.h，它将4.5中的文档翻译成了一堆常量。在这个文件里面可以看到，UART0对应了地址0x10000000(注：4.5中的文档是真正SiFive RISC-V的文档，而下图是QEMU的地址，所以4.5中的文档地址与这里的不符)。

// Physical memory layout

// qemu -machine virt is set up like this,
// based on qemu's hw/riscv/virt.c:
//
// 00001000 -- boot ROM, provided by qemu
// 02000000 -- CLINT
// 0C000000 -- PLIC
// 10000000 -- uart0 
// 10001000 -- virtio disk 
// 80000000 -- boot ROM jumps here in machine mode
//             -kernel loads the kernel here
// unused RAM after 80000000.

// the kernel uses physical memory thus:
// 80000000 -- entry.S, then kernel text and data
// end -- start of kernel page allocation area
// PHYSTOP -- end RAM used by the kernel

// qemu puts UART registers here in physical memory.
#define UART0 0x10000000L
#define UART0_IRQ 10

// virtio mmio interface
#define VIRTIO0 0x10001000
#define VIRTIO0_IRQ 1

// local interrupt controller, which contains the timer.
#define CLINT 0x2000000L
#define CLINT_MTIMECMP(hartid) (CLINT + 0x4000 + 8*(hartid))
#define CLINT_MTIME (CLINT + 0xBFF8) // cycles since boot.

// qemu puts programmable interrupt controller here.
#define PLIC 0x0c000000L
#define PLIC_PRIORITY (PLIC + 0x0)
#define PLIC_PENDING (PLIC + 0x1000)
#define PLIC_MENABLE(hart) (PLIC + 0x2000 + (hart)*0x100)
#define PLIC_SENABLE(hart) (PLIC + 0x2080 + (hart)*0x100)
#define PLIC_MPRIORITY(hart) (PLIC + 0x200000 + (hart)*0x2000)
#define PLIC_SPRIORITY(hart) (PLIC + 0x201000 + (hart)*0x2000)
#define PLIC_MCLAIM(hart) (PLIC + 0x200004 + (hart)*0x2000)
#define PLIC_SCLAIM(hart) (PLIC + 0x201004 + (hart)*0x2000)

// the kernel expects there to be RAM
// for use by the kernel and user pages
// from physical address 0x80000000 to PHYSTOP.
#define KERNBASE 0x80000000L
#define PHYSTOP (KERNBASE + 128*1024*1024)

// map the trampoline page to the highest address,
// in both user and kernel space.
#define TRAMPOLINE (MAXVA - PGSIZE)

// map kernel stacks beneath the trampoline,
// each surrounded by invalid guard pages.
#define KSTACK(p) (TRAMPOLINE - ((p)+1)* 2*PGSIZE)

// User memory layout.
// Address zero first:
//   text
//   original data and bss
//   fixed-size stack
//   expandable heap
//   ...
//   TRAPFRAME (p->trapframe, used by the trampoline)
//   TRAMPOLINE (the same page as in the kernel)
#define TRAPFRAME (TRAMPOLINE - PGSIZE)

所以，通过kvmmap可以将物理地址映射到相同的虚拟地址(因为kvmmap的前两个参数一致)。在本章后面的实验中，第一个练习是实现vmprint，这个函数会打印当前的kernel page table。我们现在跳过这个函数，看一下执行完第一个kvmmap时的kernel page table。

我们来看一下这里的输出。
----第一行是最高一级page directory的地址，这就是存在SATP或者将会存在SATP中的地址。
----第二行可以看到最高一级page directory只有一条PTE序号为0，它包含了中间级page directory的物理地址。
----第三行可以看到中间级的page directory只有一条PTE序号为128，它指向了最低级page directory的物理地址。
----第四行可以看到最低级的page directory包含了PTE指向物理地址。你们可以看到最低一级 page directory中PTE的物理地址就是0x10000000，对应了UART0。前面是物理地址，我们可以从虚拟地址的角度来验证这里符合预期。我们将地址0x10000000向右移位12bit，这样可以得到虚拟地址的高27bit(index部分)。之后我们再对这部分右移位9bit，并打印成10进制数，可以得到128，这就是中间级page directory中PTE的序号。这与之前介绍的内容是符合的。

从标志位来看(fl部分)，最低一级page directory中的PTE有读写标志位，并且Valid标志位也设置了。内核会持续的按照这种方式，调用kvmmap来设置地址空间。之后会对VIRTIO0、CLINT、PLIC、kernel text、kernel data、最后是TRAMPOLINE进行地址映射。最后我们还会调用vmprint打印完整的kernel page directory，可以看出已经设置了很多PTE。这里就不过细节了，但是这些PTE构成了我们在4.5中看到的地址空间对应关系。

之后，kvminit函数返回了，在main函数中，我们运行到了kvminithart函数。这个函数首先设置了SATP寄存器，kernel_pagetable变量来自于kvminit第一行。所以这里实际上是内核告诉MMU来使用刚刚设置好的页表。在这条指令之前，还不存在可用的(没有启动)页表，所以也就不存在地址翻译。执行完这条指令之后，程序计数器(Program Counter)增加了4。而之后的下一条指令被执行时，程序计数器会被内存中的页表翻译(程序计数器就会使用虚拟页表内存来转换)。

所以这条指令的执行时刻是一个非常重要的时刻。因为整个地址翻译从这条指令之后开始生效，之后的每一个使用的内存地址都可能对应到与之不同的物理内存地址。因为在这条指令之前，我们使用的都是物理内存地址，这条指令之后页表开始生效，所有的内存地址都变成了另一个含义，也就是虚拟内存地址。这里能正常工作的原因是值得注意的。因为前一条指令还是在物理内存中，而后一条指令已经在虚拟内存中了。比如，下一条指令地址是0x80001110就是一个虚拟内存地址。

为什么这里能正常工作呢？因为kernel page的映射关系中，虚拟地址到物理地址是完全相等的。所以，在我们打开虚拟地址翻译硬件之后，地址翻译硬件会将一个虚拟地址翻译到相同的物理地址。所以实际上，我们最终还是能通过内存地址执行到正确的指令，因为经过地址翻译0x80001110还是对应0x80001110。

问答

Frans教授：管理虚拟内存的一个难点是，一旦执行了类似于SATP这样的指令，你相当于将一个页表载到了SATP寄存器，你的世界完全改变了。现在每一个地址都会被你设置好的页表所映射。那么假设你的页表设置错误了，会发生什么呢？有人想回答这个问题吗？
学生回答：你可能会覆盖kernel data。
学生回答：会产生page fault。
Frans教授：是的，因为页表没有设置好，虚拟地址可能根本就翻译不了，那么内核会停止运行并panic。所以，如果页表中有bug，你将会看到奇怪的错误和崩溃，这导致了页表的实验将会比较难。如果你不够小心，或者你没有完全理解一些细节，你可能会导致kernel崩溃，这将会花费一些时间和精力来追踪背后的原因。但这就是管理虚拟内存的一部分，因为对于一个这么强大的工具，如果出错了，相应的你也会得到严重的后果。我并不是要给你们泼凉水，哈哈。另一方面，这也很有乐趣，经过了页表的实验，你们会真正理解虚拟内存是什么，虚拟内存能做什么。

问答

学生提问：我对于walk函数有个问题，从代码看它返回了最高级页表的PTE，但是它是怎么工作的呢？(注，应该是学生理解有误，walk函数模拟了MMU，返回的是va对应的最低级page table的PTE)

Frans教授：这个函数会返回页表的PTE，而内核可以读写PTE。我来画个图，首先我们有一个page directory，这个page directory 有512个PTE。最下面是0，最上面是511。

这个函数的作用是返回某一个PTE的指针。

这是个虚拟地址，它指向了这个PTE。之后内核可以通过向这个地址写数据来操纵这条PTE执行的物理page。(然后更新页表目录)当页表被加载到SATP寄存器，这里的更改就会生效。
学生提问：为什么它遍历了3个页表，然后只返回第一个PTE
Frans教授：不，返回的时最后一个。

从代码看，这个函数从level2走到level1然后到level0，如果参数alloc不为0，且某一个level的页表不存在，这个函数会创建一个临时的页表，将内容初始化为0，并继续运行。所以最后总是返回的是最低一级的page directory的PTE。如果参数alloc没有设置，(你在第一个PTE停止，它没有值)那么在第一个PTE对应的下一级页表不存在时就会返回。

问答

学生提问：每个进程都会有自己的3级树状页表，通过这个页表将虚拟地址翻译成物理地址。所以看起来当我们将内核虚拟地址翻译成物理地址时，我们没有考虑到页表树在物理内存中指向哪里
Frans教授：当kernel创建了一个进程，针对这个进程的页表也会从Free memory中分配出来。内核会为用户进程的页表分配几个page，并填入PTE。在某个时间点，当内核运行了这个进程，内核会将进程的根页表的地址加载到SATP中。从那个时间点开始，处理器会使用内核为那个进程构建的虚拟地址空间。
学生提问：所以内核为进程放弃了一些自己的内存，但是进程的虚拟地址空间理论上与内核的虚拟地址空间一样大，虽然实际中肯定不会这么大。
Frans教授：是的，下图是用户进程的虚拟地址空间分布，与内核地址空间一样，它也是从0到MAXVA。它有由内核设置好的，专属于进程的页表来完成地址翻译。

学生提问：但是我们不能将所有的MAXVA地址都使用吧？
Frans教授：是的我们不能，这样我们会耗尽内存。大多数的进程使用的内存都远远小于虚拟地址空间。

问答

学生提问：对于walk函数，我有一个比较困惑的地方，在写完SATP寄存器之后，内核还能直接访问物理地址吗？在代码里面看起来像是通过页表将虚拟地址翻译成了物理地址，但是这个时候SATP已经被设置了，得到的物理地址不会被认为是虚拟地址吗？
Frans教授：让我们来看kvminithart函数，这里的kernel_page_table是一个物理地址，并写入到SATP寄存器中。从那以后，我们的代码运行在一个我们构建出来的地址空间中。在之前的kvminit函数中，kvmmap会对每个地址或者每个page调用walk函数。所以你的问题是什么？
学生提问：我想知道，在SATP寄存器设置完之后，walk是不是还是按照相同的方式工作？
Frans教授：是的。它还能工作的原因是，内核设置了虚拟地址等于物理地址的映射关系，这里很重要，因为很多地方能工作的原因都是因为内核设置的地址映射关系是相同的。
学生提问：每一个进程的SATP寄存器存在哪？(SATP在哪里存放所有进程的页表地址)
Frans教授：每个CPU核只有一个SATP寄存器，但是在每个proc结构体，如果你查看proc.h，里面有一个指向页表的指针，这对应了进程的根页表物理内存地址。

学生提问：为什么通过3级页表会比一个超大的页表更好呢？
Frans教授：这是个好问题，这的原因是3级页表中大量的PTE都可以不存储。比如，对于最高级的页表里面，如果一个PTE为空，那么你就完全不用创建它对应的中间级和最底层页表，以及里面的PTE。所以，这就是像是在整个虚拟地址空间中的一大段地址完全不需要有映射一样。
学生提问：所以3级页表就像是按需分配这些映射块。
Frans教授：是的，就像前面介绍的一样。最开始你只有3个页表，一个是最高级，一个是中间级，一个是最低级的。随着代码的运行，我们会创建更多的page table diretory。

问答

学生提问：下面这两行内存不会越界(访问到free memory)吗？

Frans教授：不会。这里KERNBASE是0x80000000，这是内核在内存开始的地址。kvmmap的第三个参数是size，etext是kernel text的最后一个地址，etext - KERNBASE会返回kernel text的字节数(内核的大小)，我不确定这块有多大，大概是60-90个page，这部分是kernel的text部分。PHYSTOP是物理内存的最大位置，PHYSTOP-text是kernel的data部分。会有足够的DRAM来完成这里的映射。
e