【MIT 6.S081】实验三：page tables解析（未全部完成）

前言

第三章内容是关于内存的。需要修改函数，使得数据从用户空间到内核空间。

实验使用win10 + wsl2 Ubuntu 20.04完成。

内容总览

本实验有三个内容。

包括：

• Print a page table：写一个函数来打印页表。

reference

• ref1 ：第三章实验要求
• ref2: 知乎：MIT 6.S081 Lab3: page tables
• ref3: csdn：Mit6.S081-实验3-Page tables

十分感谢以上大佬开源的贡献。知识参考：课程内容翻译 github

内容1：Print a page table

写一个函数来打印页表。需要在启动xv6的时候，打印第一个进程，在执行exec() init的时候的页表，

1. Define a function called vmprint(). It should take a pagetable_t argument, and print that pagetable in the format described below.
2. Insert if(p->pid==1) vmprint(p->pagetable) in exec.c just before the return argc, to print the first process’s page table.

以下是输出格式. 物理地址可能不一致，但是页表项的数量以及虚拟地址应该要一致。

page table 0x0000000087f6e000
..0: pte 0x0000000021fda801 pa 0x0000000087f6a000
.. ..0: pte 0x0000000021fda401 pa 0x0000000087f69000
.. .. ..0: pte 0x0000000021fdac1f pa 0x0000000087f6b000
.. .. ..1: pte 0x0000000021fda00f pa 0x0000000087f68000
.. .. ..2: pte 0x0000000021fd9c1f pa 0x0000000087f67000
..255: pte 0x0000000021fdb401 pa 0x0000000087f6d000
.. ..511: pte 0x0000000021fdb001 pa 0x0000000087f6c000
.. .. ..510: pte 0x0000000021fdd807 pa 0x0000000087f76000
.. .. ..511: pte 0x0000000020001c0b pa 0x0000000080007000

输出说明：

1. 第一行是函数vmprint的输入参数，然后的每个PTE都输出一行，包括那些指向页表（树）更深处的PTEs
2. 用..缩进，表示树的深度。
3. 每行PTE包含：它在页表的index，pte bits?，以及从PTE中提取出来的physical address
4. 不要打印无效的PTE。

提示和理解

1. vmprint() in kernel/vm.c.
2. 在文件kernel/riscv.h的末尾可以使用宏
3. freewalk函数或许给你很多灵感。
4. 在kernel/defs.h中定义vmprint的原型，这样你才可以在exec.c中调用它。
5. 在printf调用里面使用%p输出64-bit的十六进制的PTEs地址

这里要做的东西很简单，可以跟着ref3简简单单就可以把答案做出来。

思考1：为什么使用页表

我们需要一个表单，记录了从虚拟地址到物理地址的映射关系。

假如我们直接对虚拟地址进行映射，对于每个虚拟地址，在表单中都有一个条目，如果我们真的这么做，表单会有多大？寄存器是64bit的，所以有多少个地址呢？是的，2^64个地址，所以如果我们以地址为粒度来管理，表单会变得非常巨大。实际上，所有的内存都会被这里的表单耗尽，所以这一点也不合理。

所以，实际情况不可能是一个虚拟内存地址对应page table中的一个条目。

所以真正的做法是：不要为每个地址创建一条表单条目，**而是为每个page创建一条表单条目，所以每一次地址翻译都是针对一个page。**而RISC-V中，一个page是4KB，也就是4096Bytes。这个大小非常常见，几乎所有的处理器都使用4KB大小的page或者支持4KB大小的page。也就是连续的4096个字节会被编制称一个page，一个page才有一个表单条目pte，把这个pte放进内存，这样内存压力就小得多。

思考2：如何把虚拟地址转为物理地址

为了能够完成虚拟内存地址到物理内存地址的翻译，MMU会有一个表单，表单中，一边是虚拟内存地址，另一边是物理内存地址。 举个例子，虚拟内存地址0x1000对应了一个我随口说的物理内存地址0xFFF0。这样的表单可以非常灵活。

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

如下图所示，对于虚拟内存地址，我们将它划分为两个部分，index和offset，index用来查找page，offset对应的是一个page中的哪个字节。当MMU在做地址翻译的时候，通过读取虚拟内存地址中的index可以知道物理内存中的page号，这个page号对应了物理内存中的4096个字节。之后虚拟内存地址中的offset指向了page中的4096个字节中的某一个，假设offset是12，那么page中的第12个字节被使用了。将offset加上page的起始地址，就可以得到物理内存地址。

值得注意的点：

1. 关于虚拟地址：虚拟内存地址都是64bit，这也说的通，因为RISC-V的寄存器是64bit的。但是实际上，在我们使用的RSIC-V处理器上，并不是所有的64bit都被使用了，也就是说高25bit并没有被使用。这样的结果是限制了虚拟内存地址的数量，虚拟内存地址的数量现在只有2^39个，大概是512GB。当然，如果必要的话，最新的处理器或许可以支持更大的地址空间，只需要将未使用的25bit拿出来做为虚拟内存地址的一部分即可。在剩下的39bit中，有27bit被用来当做index，12bit被用来当做offset。offset必须是12bit，因为对应了一个page的4096个字节。
2. 关于物理地址：物理内存地址是56bit。所以物理内存可以大于单个虚拟内存地址空间，但是也最多到2^{56。**大多数主板还不支持2}56这么大的物理内存，但是原则上，如果你能造出这样的主板，那么最多可以支持2^56字节的物理内存。物理内存地址是56bit，其中44bit是物理page号（PPN，Physical Page Number），剩下12bit是offset完全继承自虚拟内存地址**（也就是地址转换时，只需要将虚拟内存中的27bit翻译成物理内存中的44bit的page号，剩下的12bitoffset直接拷贝过来即可）。
3. 每个进程都有自己的页表映射。见下面的对话：

学生提问：我们从CPU到MMU之后到了内存，但是不同的进程之间的怎么区别？比如说Shell进程在地址0x1000存了一些数据，ls进程也在地址0x1000也存了一些数据，我们需要怎么将它们翻译成不同的物理内存地址。

Frans教授：SATP寄存器包含了需要使用的地址转换表的内存地址。所以ls有自己的地址转换表，cat也有自己的地址转换表。每个进程都有完全属于自己的地址转换表。

思考3：为什么使用多级页表

通过前面的第一步，我们现在是的地址转换表是以page为粒度，而不是以单个内存地址为粒度，现在这个地址转换表已经可以被称为page table了。但是目前的设计还不能满足实际的需求。

如果每个进程都有自己的page table，那么每个page table表会有多大呢？

这个page table最多会有2^27个条目（虚拟内存地址中的index长度为27，即128MB个PTE），这是个非常大的数字。如果每个进程都使用这么大的page table，进程需要为page table消耗大量的内存，并且很快物理内存就会耗尽。假如每个PTE大小是4个字节，那么每个进程得腾出512MB的空间为每个进程做从虚拟地址到物理地址的转换。

因此我们需要想方法降低占用的内存，多级的结构的页表，就可以解决这个问题。 这种方式的主要优点是，如果地址空间中大部分地址都没有使用，你不必为每一个index准备一个条目。

举个例子，如果你的地址空间只使用了一个page，4096Bytes，在最高级，你需要一个page directory。在这个page directory中，你需要一个数字是0的PTE，指向中间级page directory。所以在中间级，你也需要一个page directory，里面也是一个数字0的PTE，指向最低级page directory。所以这里总共需要3个page directory（也就是3 * 512个条目）。而在前一个方案中，虽然我们只使用了一个page，还是需要2^27个PTE。这个方案中，我们只需要3 * 512个PTE。所需的空间大大减少了。这是实际上硬件采用这种层次化的3级page directory结构的主要原因。

我们之前提到的虚拟内存地址中的27bit的index，实际上是由3个9bit的数字组成（L2，L1，L0）。前9个bit被用来索引最高级的page directory。一个directory是4096Bytes，就跟page的大小是一样的。Directory中的一个条目被称为PTE（Page Table Entry）是64bits，就像寄存器的大小一样，也就是8Bytes。所以一个Directory page有512个条目。

下面是最关键最核心的理解：

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

思考4：对PTE的理解

首先，PTE既不是虚拟地址，也不是物理地址，它是一种放在页表里面的数据。在多层页表里面也叫页目录项（Page Directory Entries, PDE）

• 前10位为保留位，不使用。
• 中间44位为存储下一个页表的地址
• 后10位是页表的标记位，标记位的理解如下：

1. 指示PTE是否存在：如果没有设置它，对页面的引用将导致异常（即不允许）。
2. PTE_R控制是否允许将指令读取到该页面。
3. PTE_W控制是否允许将指令写入该页面。
4. PTE_X控制CPU是否可以将页面的内容解释为指令并执行它们。
5. PTE_U控制是否允许用户模式下的指令访问该页面；如果未设置PTE_U，则PTE只能在监控模式下使用。
6. 其他标志位并不是那么重要，他们偶尔会出现，前面5个是重要的标志位。但我查了一下书
   1. Acessed bit用于追踪页是否被访问过，在页面替换算法的时候会用到
   2. Dirty bit用于标志页面被带入内存后是否被修改过
   3. …其他跟书上不一致

做法与代码

这里我贴上最核心的vmprint代码。全部代码可以参考ref3

void _vmprint(pagetable_t pagetable, int level)
{
  //思考：为什么是512(也就是问系统的内存模型是怎么样的)
  for (int i = 0; i < 512; i++)
  {	
    
    pte_t pte = pagetable[i];
    //跳过无效的
    if (pte & PTE_V)
    {
      //思考：如何把虚拟地址转为物理地址
      uint64 pa = PTE2PA(pte);
      for (int j = 0; j < level; j++)
      {
        if (j)
          printf(" ");
        printf("..");
      }
      printf("%d: pte %p pa %p\n", i, pte, pa);
      //思考：为什么是(PTE_R | PTE_W | PTE_X)都为0才开始递归
      if ((pte & (PTE_R | PTE_W | PTE_X)) == 0)
      {
        _vmprint((pagetable_t)pa, level + 1);
      }
    }
  }
}

void vmprint(pagetable_t pagetable)
{
  printf("page table %p\n", pagetable);
  _vmprint(pagetable, 1);
}

内容2（未完成）：A kernel page table per process

Xv6 有一个内核页表(kernel page table)，每当它在内核中执行时都会使用它。 内核页表直接映射到物理地址，即内核虚拟地址 x 映射到物理地址 x。

Xv6 还为每个进程的用户地址空间提供了一个单独的页表，仅包含该进程的用户内存的映射（process’s user address space），从虚拟地址零开始。因为内核页表不包含这些映射，所以用户地址在内核中是无效的。因此，当内核需要使用在系统调用中传递的用户指针（例如，传递给 write() 的缓冲区指针）时，内核必须首先将指针转换为物理地址。

本节和下一节的目标是允许内核直接dereference用户指针。

1. 修改内核，以便每个进程在内核中执行时都使用自己的内核页表副本（its own copy of the kernel page table）
2. 为了每个进程维护一个内核页表，你需要修改proc结构体，并修改调度器**在切换进程时切换内核页表。**这时候，每个进程的内核页表应该与现有的全局内核页表相同。

阅读本作业开始时提到的书籍章节和代码； 了解虚拟内存代码的工作原理后，将更容易正确修改虚拟内存代码。 页表设置中的错误可能会由于缺少映射而导致陷阱，可能导致加载和存储影响物理内存的意外页面，并可能导致从错误的内存页面执行指令。

提示和理解

1. 在 proc结构体中，添加一个字段来表示内核页表
2. 为新进程生成内核页表的合理方法是实现·kvminit 的修改版本，该版本生成新页表，而不是修改 kernel_pagetable。您需要从 allocproc 调用此函数。
3. **确保每个进程的内核页表都有该进程的内核堆栈的映射。**在未修改的 xv6 中，所有内核堆栈都在 procinit 中设置。您需要将部分或全部功能移至 allocproc。
4. 修改 scheduler() 以将进程的内核页表加载到内核的 satp 寄存器中（请参阅 kvminithart 以获得灵感）。 在调用w_satp()之后不要忘记调用 sfence_vma()。
5. scheduler() 应该在没有进程运行时使用 kernel_pagetable。
6. 在freeproc中释放进程的内核页表。
7. 您将需要一种方法来释放页表，而无需同时释放叶物理内存页面。
8. vmprint 在调试页表时可能会派上用场。
9. 修改xv6功能或添加新功能都可以； 您可能至少需要在 kernel/vm.c 和 kernel/proc.c 中执行此操作。 （但是，不要修改 kernel/vmcopyin.c、kernel/stats.c、user/usertests.c 和 user/stats.c。）
10. 缺少页表映射可能会导致内核遇到页面错误。 它将打印一个包含 sepc=0x00000000XXXXXXXX 的错误。 您可以通过在 kernel/kernel.asm 中搜索XXXXXXXX来找出故障发生的位置。

做法与代码

这里跟了ref2和ref3的做法都没有对，说得不够详细。

我自己没有能力去完全理解，只能理解个大概，所以暂时放过。

所以后面实验3也暂时放过，先看后面的实验。

后话

为了完成这个实验我还专门回去看了《操作系统导论》的关于虚拟内存、分页、多级分页的内容，书上内容是理解了，但是到这里代码就不知道怎么操作了。

先往前走吧，后面需要再回来。

欢迎留言交流。