page tables 以及 Lab3 心得

布满荆棘的人生 2024-03-23 23:46 53阅读 0赞

## 一、地址空间 ##

上一节的一个话题是 **OS 的隔离性**，主要包括两种隔离：

1.  OS 内核和用户程序之间的隔离
2.  用户程序之间的隔离

这两种隔离具体来说都属于“**内存隔离**”，内存隔离的一种实现方式就是“**地址空间**”

> CSAPP 中给出地址空间的准确定义：**一个n位的地址空间，包含2^n个地址**，现代OS一般支持32位或者64位虚拟地址空间。同一个物理地址，在不同的地址空间中有着不同的地址。

地址空间的概念简单且直观，我们给包括**内核在内**的**所有程序**专属的地址空间。s**hell 和 cat 程序都有自己的地址空间，互相都不知道对方地址空间的存在**，所以现在我们的问题是如何在一个物理内存上，创建不同的地址空间，因为归根到底，物理上的 DRAM 芯片是所有程序共用的。

[![image-20220701101711838][]][image-20220701101711838 1]

### 页表（page table） ###

在共享的物理内存上如何创建出不同程序的地址空间呢？

最常见的方法，同时也是非常灵活的一种方法就是使用**页表**（Page Tables）。**页表就是一个数组**，他的元素就是一个个**页表条目（PTE）**，使用 页表可以实现**虚拟内存地址**到**物理内存地址**的翻译，页表**存储在内存中，由 OS 负责维护，内存管理单元（Memory Management Unit） 有查询页表的权限，MMU由一般被集成在 CPU 中。**

特别注意：**MMU是硬件的一部分而不是操作系统的一部分**

以下图为例，当一条指令被传入 CPU 中，如果指令中含有地址，CPU 会被为指令中的地址是**虚拟地址**，然后将这个虚拟地址**通过 MMU 翻译**为物理地址，从而去物理内存上找到相应的值。

[![image-20230811162146194][]][image-20230811162146194 1]

到目前位置，一切看上去很简单、很美好，但**魔鬼隐藏在细节中**，下面是要注意的细节

1.  页表存在哪里？**页表是保存在内存中的**，MMU只是会去查看 page table，MMU并不会保存 page table
2.  在 RISC-V 上 **SATP 的寄存器**会存储页表的地址（这里简单思考一下，存的是物理地址还是虚拟地址？肯定是物理啊！不然成了地址翻译套娃了，永远得不到物理地址）
3.  page table 中 PTE 的**粒度是：page**，所以这里要清楚，**内存中每个字节都有自己的地址**没错，但不是每个字节都有对应的PTE，是**每一页才有对应的PTE**（RISC-V中，一个page是4KB，4096Bytes）
4.  **页表翻译的过程**，以下图为例说明，一个虚拟地址有 64bit，而 xv6 运行在 **Sv39 模式**下，即 64bit 的虚拟地址只用到了低 39bit，高 25bit 没有使用。`2^39 bytes = 512 GB`，所以 RISCV 虚拟地址空间有 512GB。
    
    1.  将 39 bit 虚拟地址分为 2 部分，前 27 bit 称为 index，后 12bit 称为 offset
    2.  index 部分就是页表的索引，取出页表中第 index 条PTE，PTE 有 54bit ，前 44bit 称为 PPN（Physical Page Number 物理页号），后 10bit 称为 Flags，目前我们只关注前 44bit
    3.  **将 PPN 和 offset 拼接到一起**，就是翻译出来的物理地址
    
    [![image-20221115210518787][]][image-20221115210518787 1]
    
    附一张 CSAPP 的课件图，从宏观上再次理解一下地址翻译的过程：
    
    [![image-20220907201648854][]][image-20220907201648854 1]

> 思考：offset 的含义是什么，为什么是 12bit？
> 
> 回答：offset 是指一个字节在一个 paeg 中的偏移量，一个 page 是 4096KB，即 2^12字节，由于 RISC-V 是字节寻址，每个地址代表一个字节，所以一个 page 中就有 2^12个地址，而 offset 使用 12bit 就可以覆盖这 2^12 个地址
> 
> 比如 offset 是 0000 0000 0101，表示的是这个 page 中的第 5 个字节（从 0 开始）

关于 Sv39 模式：

> 为什么使用 39bit，是因为 RISC-V 的设计者认为这个数字在可预测的将来可以容纳足够多的 I/O设备 和 DRAM芯片；如果需要更多的虚拟地址，RISC-V设计者已经定义了具有48位虚拟地址的Sv48模式

### 多级页表 ###

#### 单级页表的困境：巨大的内存占用 ####

为什么要提出多级页表的概念，简单计算一下就知道，以 XV6 为例，现有以下事实：

*  一条 PTE 占 8bytes：一条 PTE 有54bit，由于可以扩展到 64bit，所以我们以一条 PTE 64bit = 8bytes 计算
 *  一页 4KB
 *  RISCV 虚拟地址空间有 239 bytes = 512GB

开始计算：

1.  虚拟地址空间一共有 239 / 4kB = 239 / 212 = 227 页（ 227 ≈ 1 亿 3 千万，意味着**页表中有约 1 亿 3 千万条 PTE**）
2.  页表需要的内存为 ：227 \* 8bytes = 230 bytes = 1GB

计算结果是不是大跌眼镜？而且这只是一张页表就需要 1GB 的内存，那 n 个用户进程可是有 n 张不同的页表的，难道计算机跑 10 个进程，光页表就占据 10GB 内存吗？

很显然计算结果告诉我们，**由于GB 级别的内存占用，页表不能简单粗暴地单级存储，所以多级页表的概念被提出来了**

#### 多级页表的概念以及翻译过程 ####

上一节知道，以 RISC-V 的 sv39 模式为例，有效虚拟地址空间是39位，一页大小为4K字节（212 byte），一条PTE为 8 byte，**需要 1GB的内存空间存放页表**！

解决方案就是使用**层次结构的页表-多级页表**，这个结构的关键就是，之前的页表PTE的内容是内存的**物理页号PPN+Flags**，而现在一级页表PTE的内容是**下一级页表的基地址+Flags**（之所以叫基地址，是因为**补 0** 后是下一级页表的最低地址），直到**最后一级**页表PTE的内容才是内存的**"物理页号PPN+Flags"**

以下图为例，展示多级页表的翻译过程：

1.  虚拟地址依旧是 27bit index + 12bit offset，但是 **27bit 的 index 被分成了 3 部分，每部分 9bit**，9bit 意味着可以表示29 = 512 条PTE，以一级页表为例，**每条 PTE 对应 一张二级页表**，所以 512 条 PTE 对应 512 张二级页表
2.  从 satp 寄存器中找到**一级页表**的物理地址，然后利用L2 的 9bit 在一级页表中定位一条 PTE，其中的 PPN + 12个 0 就是某张二级页表的物理地址，然后利用 L2 的 9bit在这张二级页表中定位一条 PTE
3.  利用二级页表中某条 PTE 中的 PPN，+ 12个 0的得到三级页表的物理地址，然后利用 L0 的 9bit 在三级页表中定位一条 PTE，这条 PTE + offset 就是最终的物理地址

[![image-20230811213654474][]][image-20230811213654474 1]

#### CSAPP：多级页表为什么节省内存 ####

**这其实是一个很棒的面试题，这一问能想通，说明学习者对于页表的知识真正"参透"了。**

以一个32位系统（虚拟地址有32bit），一页4KB（212bytes），每条PTE 4bytes为例，解释一下多级页表如何节省空间：

*  单级页表：需要为32位地址的每一个 page 提供一条PTE，即**这张页表必须对整个虚拟地址空间做到全覆盖**（因为如果虚拟地址在页表中找不到对应的页表项，地址翻译无法继续，整个计算机系统就无法工作了），页表一共需要 232 / 212 \* 4 byte = 4MB 内存空间才能覆盖全部 4GB 的地址空间。
 *  多级页表：如下图所示，如果只需要使用部分虚拟地址空间，比如图中的 `VP 0~VP 2047` 以及 `VP 9215`，只需要1张4KB 大小的一级页表，就可以覆盖了整个地址空间：4GB。再加上 3 张二级页表，就可以对`VP 0~VP 2047、VP 9215`完成映射，一共 4 张页表共16KB。对比单张页表的 4MB 内存空间节省很多。

[![image-20220706161252168][]][image-20220706161252168 1]

一个至关重要的问题是：这里**为什么可以只使用部分空间**而不用像单级页表那样全部覆盖（每一个 page 都有 PTE）呢？其实**多级页表也是做了全覆盖的，那就是第一级页表**，在多级页表中，一级页表是常驻内存的，而且一级页表一条 PTE 就覆盖了 4MB 的内存、整张一级页表覆盖了 4GB 内存，对比单级页表一条 PTE 就映射了 4KB 的内存，效率大大提升。

所以使用多级页表能够节省内存的原因有以下两个，但重要的是在这个前提下：**多级页表的一级页表依旧做到了内存全覆盖**：

1.  一级页表覆盖了整个4GB虚拟地址空间，但**如果某个一级页表的PTE没有被用到，那么二级页表和三级页表就不会存在**，这是一种巨大的节约（xv6book也有类似的表述：在大范围的虚拟地址没有映射的常见情况下，三层结构可以省略整个页面目录）
2.  只有**一级页表**（与最经常使用的二级页表）**常驻主存**，其他页表可以在从磁盘调入

所以总结一下就是：**无论是单级页表还是多级页表，他们都需要、也都做到了内存（虚拟）地址的全覆盖**，但是多级页表更加灵活，如果某个一级页表的PTE没有被用到，那么**二级页表和三级页表就不会存在**，这是一种巨大的节约！而单级页表只能老老实实对所有虚拟地址进行映射，因为如果不这样的话，单级页表就不是“全覆盖”，地址翻译就无法进行了

参考：[操作系统中的多级页表到底是为了解决什么问题？ - 知乎][-]

### PTE 的辅助位 ###

前面讲过一条 PTE 有 54bit，44bit 属于 PPN，10bit 属于 Flags，又称为辅助位

[![image-20221116161829987][]][image-20221116161829987 1]

*  V-bit ：Valid，有效位，如果Valid bit位为1，那么表明这是一条**合法的PTE**，可以用来做地址翻译，否则，不能使用这条PTE，因为**这条PTE并不包含有用的信息**。（用 CSAPP 中的概念解释的话，**有效 = 该页处于“已缓存”状态**，具体见下面的引用）
 *  R-bit ：Readable，该页是否允许被读
 *  W-bit ：Writable，该页是否允许被写
 *  X-bit ：Executable，CPU是否可以将页面的内容解释为指令并执行
 *  U-bit：User， 是否（只）允许在 user mode 下使用该条 PTE

> CSAPP：任何时刻，虚拟页都可分为三种类型
> 
> [![image-20220701111109352][]][image-20220701111109352 1]
> 
>  *  未分配的：VM系统还未分配或创建的页，**不占用任何磁盘空间**，上图中的VP0、3（在磁盘上还不存在！）这是一种为了和下面两个类型统一的表达方式，因为我们不至于、不必要把虚拟地址空间中的每个页面都存储起来
>  *  已缓存：已缓存在内存中的已分配的页，上图中的VP1、4、6
>  *  未缓存：未缓存在内存中的已分配页，上图中的VP2、5、7

注意，PTE 的这些辅助位是给分页硬件（paging hardware）看的，在xv6 book 中它被频繁提及，分页硬件总是和页表交互。

## 二、支持虚拟内存的硬件 ##

这里有一块 RISC-V 主板，中间是RISC-V处理器，处理器处理器旁边就是DRAM芯片。处理器下方就是DRAM芯片。一个主板是由 CPU、DRAM、以及各种外设（如网卡、通信接口、定时器、PWM、DMA 等）组成的，**DRAM 和各种外设都有自己地址，这是由硬件设计者决定的**，当我们需要操作外设或者存取数据时，**只需要往对应地址发送信号或者数据**，这是最基本的计算原理。

[![image-20230814175148317][]][image-20230814175148317 1]

在常见的地址映射方案中，当 CPU 访问物理地址空间时，若得到的物理地址**小于** 0x80000000，则可以认为该访问是针对各类 **I/O 设备（外设）**的操作；而若得到的物理地址**大于**等于 0x80000000，则可以认为该访问是针对 **DRAM** 的操作。下面的讲解也遵循这个惯例。

下图左边是 **xv6 内核的虚拟地址空间**，右半部分是一块 RISC-V 主板的**物理地址**，该结构**完全由硬件设计者决定**，上半部分是**物理内存**或者说是 DRAM，右边下半部分是**I/O设备。**

[![image-20221116170053352][]][image-20221116170053352 1]

### 右边的物理地址 ###

细看右边的物理地址：

*  最下面（地址为0）是未被使用的地址；
 *  地址 0x1000 是 **boot ROM** 的物理地址，当主板上电后，**做的第一件事情就是运行存储在 boot ROM 中的代码**。这里的代码会启动 boot loader ，**把 xv6 kernel 加载到内存中**的 0x8000000 处。当 boot 完成之后，会跳转到地址0x80000000，开始执行 OS 的代码
 *  PLIC是中断控制器（Platform-Level Interrupt Controller）
 *  CLINT（Core Local Interruptor）也是中断的一部分。地址0x02000000对应CLINT，当你向这个地址执行读写指令，你是向实现了CLINT的芯片执行读写。**（看样子是在读写物理内存，但由于地址小于 0x80000000，实际上是以这种形式操作外设）**
 *  UART0（Universal Asynchronous Receiver/Transmitter）负责与Console和显示器交互。
 *  VIRTIO disk，与磁盘进行交互。

### 左边的 XV6 的内核的虚拟地址空间 ###

XV6 内核会设置好内核使用的虚拟地址空间，也就是上图左边的地址分布，因为**设计者想让XV6尽可能的简单易懂**，所以左侧低于 PHYSTOP（0x8800 0000） 的虚拟地址，使用的是直接映射的方式，比如虚拟地址 0x02000000 对应物理地址 0x02000000

这里需要注意一点就是权限，XV6 的虚拟地址空间每一段都有不同的权限。例如 Kernel text page 被标记为 R-X，意味着你可以读它，也可以在这个地址段执行指令，但是你不能向Kernel text写数据。

[![image-20230814182948555][]][image-20230814182948555 1]

## 三、XV6 中支持虚拟内存的代码 ##

阅读完第二节，了解了主板的物理地址结构和 XV6 内核的虚拟地址空间结构，那么**这两者是如何映射到一起的**？其实仔细想想就知道了，映射完成意味着可以根据 va 找到 pa，那么怎么根据 va 找 pa？当然是 page table 啦！所以**映射就是在 page table 中把这两者的关系记录下来，就意味着映射完成**！

来看代码：

// Initialize the one kernel\_pagetable void kvminit(void) \{ kernel\_pagetable = kvmmake(); \} //------------------------------------------------------------------- // Make a direct-map page table for the kernel. pagetable\_t kvmmake(void) \{ pagetable\_t kpgtbl; kpgtbl = (pagetable\_t) kalloc(); memset(kpgtbl, 0, PGSIZE); // uart registers kvmmap(kpgtbl, UART0, UART0, PGSIZE, PTE\_R | PTE\_W); // virtio mmio disk interface kvmmap(kpgtbl, VIRTIO0, VIRTIO0, PGSIZE, PTE\_R | PTE\_W); // PLIC kvmmap(kpgtbl, PLIC, PLIC, 0x400000, PTE\_R | PTE\_W); // map kernel text executable and read-only. kvmmap(kpgtbl, KERNBASE, KERNBASE, (uint64)etext-KERNBASE, PTE\_R | PTE\_X); // map kernel data and the physical RAM we'll make use of. kvmmap(kpgtbl, (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(kpgtbl, TRAMPOLINE, (uint64)trampoline, PGSIZE, PTE\_R | PTE\_X); // allocate and map a kernel stack for each process. proc\_mapstacks(kpgtbl); return kpgtbl; \}

这里的逻辑其实非常简单，来看我帮你梳理一下，以主板上`UART0`的物理地址`0x1000 0000`为例，你现在有了这个物理地址，想要在内核的页表中添加一条 PTE，将虚拟地址`0x1000 0000`与物理地址对应起来，所以：

1.  先在页表中找到这个 va 对应的 pte，找不到则使用 kalloc 分配一个新 page
2.  然后修改这条 pte，使其指向物理地址`0x1000 0000`

我们来详解这两步：

1.  页表中寻找 va 对应的 pte，这是 **walk() 函数**的责任，walk()函数模拟了三级页表中根据 va 寻找 pte 的流程，之所以说模拟，是因为在真实的计算机中，这个寻找过程是 MMU 实现的，而不是 OS 实现的。
    
    [![image-20230814190446420][]][image-20230814190446420 1]
2.  修改这条 pte 内容，将其指向物理地址
    
    [![image-20230814195648180][]][image-20230814195648180 1]

总结 kvminit() 的效果就是，**创建使用 kalloc() 函数分配一个 4KB 的 page 作为内核页表，然后按照 XV6 内核的虚拟地址空间结构，将所有的虚拟地址和物理地址一一映射**。下图中各色矩形就是映射结果：

[![2623804d6ab5408c2e5605d9433356e7.png][]][2623804d6ab5408c2e5605d9433356e7.png 1]

其中 `proc_mapstacks()`函数比较有趣，它的作用是，计算了 **TRAMPOLINE** 地址（最大的虚拟地址）往下的 **1+64\*2+1 = 130页**的地址，将这些虚拟地址映射到了64个 kalloc 分配的新页上，va使用 **KSTACK** 的计算方式，使得 va 的值依次是：

&TRAMPOLINE - 2\*PGSIZE

&TRAMPOLINE - 4\*PGSIZE

&TRAMPOLINE - 6\*PGSIZE

......

这样 va 都是间隔的，所以在虚拟空间上形成了guard page包围 kstack0～63 的格局，最终实现把这些虚拟地址映射到 kalloc 分配的的内存空间（物理的 DRAM芯片）

\#define KSTACK(p) (TRAMPOLINE - ((p)+1)\* 2\*PGSIZE)

详细分析见下图：

[![image-20230814201353059][]][image-20230814201353059 1]

## 四、Lab3 ：pgtbl 心得 ##

### Lab3.1 speed up the systemcall ###

从上一个 lab 中可以知道，要想进行系统调用，必须有从用户态进入到内核态才可以实现这种调用。

以系统调用：getpid() 为例，正常流程是：在用户态使用 ecall 实现系统调用，执行 ecall 后进入内核态，在内核态中调用 myproc() 得到当前进程 proc 结构体，返回 proc->pid 即可

而 lab 想让我们实现的是：直接在“每个进程”启动时，指定一个名为 USYSCALL 的 page 存放 pid，并且设置该 page 的权限为 R | U，U 是指可以该 PTE 可以 user mode下使用，所以不用陷入内核态就可以使用这条 PTE 找到存放 pid 的 page（**小小的吐槽，一个 page 就放一个 pid，属实浪费......**）

根据提示可以很容易写出来：

提示： 可以使用kernel/proc.c中的proc\_pagetable()执行映射。 选择只允许用户空间读取页面的权限位。 您可能会发现 mappages() 是一个有用的实用程序。 不要忘记在allocproc()中分配和初始化这个页面。 确保在freeproc()中释放页面。

**首先定义 USYSCALL 的虚拟地址**

\#define USYSCALL (TRAPFRAME - PGSIZE) struct usyscall \{ int pid; // Process ID \};

那么如何实现在“创建每个进程时”完成映射呢？分析源码**创建进程**只有两种情况，一种是**最初的 userinit()**，另一种就是以后都用的 fork() 来创建进程，这两种创建进程的情况都是使用 allocproc() 函数：从 process table 中返回一个未使用的状态的进程，所以在 allocproc() 中分配这个页面的**物理地址：p->usyscall**，模仿上面的分配 trapframe page 的函数，可以很快写出来：

// in allocproc() struct proc \*p; // Allocate a trapframe page. if((p->trapframe = (struct trapframe \*)kalloc()) == 0)\{ freeproc(p); release(&p->lock); return 0; \} // 为 USYSCALL page（虚拟地址）分配物理页面 if((p->usyscall = (struct usyscall \*)kalloc()) == 0)\{ freeproc(p); release(&p->lock); return 0; \} // 初始化 USYSCALL page p->p\_usyscall->pid = p->pid

在 allocproc() 中要为进程分配对应的页表，使用 proc\_pagetable() 函数，所以**在这个函数中将 kalloc() 分配的物理地址p->usyscall 和虚拟地址 USYSCALL 完成映射**：

// in proc\_pagetable() // 将 kalloc() 分配的物理地址p->usyscall 和虚拟地址 USYSCALL 映射 if(mappages(pagetable, USYSCALL, PGSIZE, (uint64)p->usyscall, PTE\_R | PTE\_U) < 0)\{ uvmunmap(pagetable, TRAMPOLINE, 1, 0); uvmunmap(pagetable, TRAPFRAME, 1, 0); uvmfree(pagetable, 0); return 0; \}

根据提示最后要确保在 freeproc() 中释放页面。

// Free a process's page table, and free the // physical memory it refers to. void proc\_freepagetable(pagetable\_t pagetable, uint64 sz) \{ uvmunmap(pagetable, TRAMPOLINE, 1, 0); uvmunmap(pagetable, TRAPFRAME, 1, 0); //在 freeproc() 中释放页面 uvmunmap(pagetable, USYSCALL, 1, 0); uvmfree(pagetable, sz); \}

### Lab3.2 Print a page table ([easy][]) ###

这个 lab 要求启动 XV6 时，打印出页表的内容。定义函数 `vmprint()` ，它接收一个 `pagetable_t` 类型的参数，并且按照下面的格式打印：

page table 0x0000000087f6b000 //第一行显示vmprint的参数,即页表指针 ..0: pte 0x0000000021fd9c01 pa 0x0000000087f67000 // .. 表示第1层深度的页表，pte后就是pte的内容，截取后10bit，再补足12个0就是pa .. ..0: pte 0x0000000021fd9801 pa 0x0000000087f66000 // .. .. 表示第2层深度的页表，pa后就是物理地址 .. .. ..0: pte 0x0000000021fda01b pa 0x0000000087f68000 .. .. ..1: pte 0x0000000021fd9417 pa 0x0000000087f65000 .. .. ..2: pte 0x0000000021fd9007 pa 0x0000000087f64000 .. .. ..3: pte 0x0000000021fd8c17 pa 0x0000000087f63000 ..255: pte 0x0000000021fda801 pa 0x0000000087f6a000 .. ..511: pte 0x0000000021fda401 pa 0x0000000087f69000 .. .. ..509: pte 0x0000000021fdcc13 pa 0x0000000087f73000 .. .. ..510: pte 0x0000000021fdd007 pa 0x0000000087f74000 .. .. ..511: pte 0x0000000020001c0b pa 0x0000000080007000 init: starting sh

这个函数很简单，给出提示，可以仿照 freewalk 函数的递归写法来遍历页表，但是也就三层，我就直接循环遍历了：

//print pte void vmprint(pagetable\_t level2)\{ //好，现在已经拿到了宝贵的顶级页表指针 pagetable，接下来打印 pte printf("page table %p\\n", level2); //第一行直接打印pagetablr，得到页表地址 //接下来遍历这个页表，找到PTE\_V有效的就打印 //这个打印顺序很有趣，就是很符合递归的顺序 for(int i = 0; i < 512; i++) \{ pte\_t level2\_pte = level2\[i\]; if(level2\_pte & PTE\_V) \{ printf("..%d: ", i); // 注意%p 用来打印指针变量的值 printf("pte %p pa %p\\n", level2\_pte, PTE2PA(level2\_pte)); uint64 level1 = PTE2PA(level2\_pte); for(int j = 0; j < 512; j++) \{ pte\_t level1\_pte = ((pagetable\_t)level1)\[j\]; if(level1\_pte & PTE\_V) \{ printf(".. ..%d: ", j); printf("pte %p pa %p\\n", level1\_pte, PTE2PA(level1\_pte)); uint64 level0 = PTE2PA(level1\_pte); for(int k = 0; k < 512; k++) \{ pte\_t level0\_pte = ((pagetable\_t)level0)\[k\]; if(level0\_pte & PTE\_V) \{ printf(".. .. ..%d: ", k); printf("pte %p pa %p\\n", level0\_pte, PTE2PA(level0\_pte)); \} \} \} \} \} \} \}

使用递归的难点是每一层打印的点点 “.. .. ”是和标准输出不一样的，但这也不是大问题，下面给出递归的写法：

void vmprint(pagetable\_t pagetable) \{ if (printdeep == 0) printf("page table %p\\n", (uint64)pagetable); for (int i = 0; i < 512; i++) \{ pte\_t pte = pagetable\[i\]; if (pte & PTE\_V) \{ for (int j = 0; j <= printdeep; j++) \{ printf(".."); \} printf("%d: pte %p pa %p\\n", i, (uint64)pte, (uint64)PTE2PA(pte)); \} // pintes to lower-level page table if((pte & PTE\_V) && (pte & (PTE\_R|PTE\_W|PTE\_X)) == 0)\{ printdeep++; uint64 child\_pa = PTE2PA(pte); vmprint((pagetable\_t)child\_pa); printdeep--; \} \} \}

### Lab 3.3 Detect which pages have been accessed ###

在 lab 的这一部分，将向 xv6 添加一个新特性：检查指定页表中的**访问位**，并向用户空间返回访问信息：即实现 **pgaccess()**，这是一个**报告哪些页面已被访问的系统调用**。系统调用接受三个参数：

1.  base，这是一个 page 的地址，从这个 page 开始检查
2.  len，需要检查页面的数量。
3.  mask，这是一个用户空间的地址，用来存储 bitmask，bitmask 反映了哪些 page 被访问

实现其实非常简单，要检查一个 page 是否被访问，只需要检查 PTE 中的 A bit 是否被设置，难点是理解 pgacess 的作用。

lab 要求**阅读测试文件**来分析出 pgaccess() 函数的作用：

void pgaccess\_test() \{ char \*buf; unsigned int abits; printf("pgaccess\_test starting\\n"); testname = "pgaccess\_test"; buf = malloc(32 \* PGSIZE); if (pgaccess(buf, 32, &abits) < 0)//pgaccess需要自己实现，自己定义返回被访问的页数总和 err("pgaccess failed"); buf\[PGSIZE \* 1\] += 1;//buf\[1024\],访问第1页第一个字节（最早是0页） buf\[PGSIZE \* 2\] += 1;//buf\[2048\],访问第2页第一个字节（最早是0页） buf\[PGSIZE \* 30\] += 1;//访问第30页第一个字节 if (pgaccess(buf, 32, &abits) < 0) err("pgaccess failed"); printf("abits: %d\\n", abits); if (abits != ((1 << 1) | (1 << 2) | (1 << 30)))//pgacess的效果就是设置abits，由于第1,2,30页被访问，所以abits的1,2,30位被设置为1 err("incorrect access bits set"); free(buf); printf("pgaccess\_test: OK\\n"); \}

malloc分配了 32 page 给 buf，然后访问第1、2、30个page，pgaccess函数就输出了maskbits，将maskbitsd的第1、2、30bit设置为1，注意pgacess不能直接返回maskbits（第四章会有说明，可以直接返回，但是有问题，因为 xv6 只能返回 8bytes 的数据，如果是复杂一点的结构体就拉了），所以要使用 copyout 函数将 maskbits 返回到用户空间

使用argint函数和argaddr函数进行系统调用传参

int sys\_pgaccess(void) \{ // lab pgtbl: your code here. uint64 base; int len; uint64 mask; argaddr(0, &base); argint(1, &len); argaddr(2, &mask); return pgaccess((void\*)base, len, (void\*)mask); \}

先不用理解原理，传参原理第四章节会将，现在知道怎么用就好了。

在proc.c中实现 `pgaccess`

int pgaccess(void \*base, int len, void \*mask) \{ void \*pg = base;//用来遍历所有页的指针 struct proc \*proc = myproc(); uint32 ans = 0; pagetable\_t pagetable = proc->pagetable; for(int i = 0; i < len; i++) \{ pg = base + PGSIZE \* i;//这里void \*类型的指针加法效果和 char \* 是一样的：即指针加1代表加1字节 pte\_t \*pte = walk(pagetable, (uint64)pg, 0);//注意walk要求 pg 进行 void\* -> uint64 的类型转换 // 检查PTE\_A是否设置 if (pte != 0 && ((\*pte) & PTE\_A))\{ ans = ans | (1 << i); \*pte &= ~PTE\_A; // clear PTE\_A 这里要对检查PTE\_A是否设置后，一定要清除。因为检查本身就会导致 PTE\_A 被 set \} \} //return ans; return copyout(pagetable, (uint64)mask, (char \*)&ans, sizeof(int)); \}

OK，以上就是 MIT-OS-04 的所有内容了，比起后面学的 CMU15-445 和 MIT6.824 来说，返回头来看这些 lab 发现非常简单，但当时记得写的还是有点痛苦的，或许是我确实成长了吧！这次复习，让我真正理解了一个以前没想清楚的知识点：为什么多级页表节省空间？为什么多级页表可以不创建没有映射的 PTE，单级页表却要一条都不能少？关键在于"**全部映射**"这四个字~

[image-20220701101711838]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/41f1dec6c4bd402595b7b0667bbd1766.png
[image-20220701101711838 1]: https://img2023.cnblogs.com/blog/2174405/202308/2174405-20230814214633874-10934348.png
[image-20230811162146194]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/a62f1627a8b64f91bc00faad4fa59375.png
[image-20230811162146194 1]: https://img2023.cnblogs.com/blog/2174405/202308/2174405-20230814214633995-2013893078.png
[image-20221115210518787]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/d8d06d67f22b426caff15122cafd4f7a.png
[image-20221115210518787 1]: https://img2023.cnblogs.com/blog/2174405/202308/2174405-20230814214633880-1691376509.png
[image-20220907201648854]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/8ef15da0bc1c48148f163a0b62c52ff6.png
[image-20220907201648854 1]: https://img2023.cnblogs.com/blog/2174405/202308/2174405-20230814214633963-1290814452.png
[image-20230811213654474]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/f2c6130b13504ad9aa8a2256feea3bbb.png
[image-20230811213654474 1]: https://img2023.cnblogs.com/blog/2174405/202308/2174405-20230814214633996-1022275490.png
[image-20220706161252168]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/1f064a710c5d48f28b6af0d731870ee1.png
[image-20220706161252168 1]: https://img2023.cnblogs.com/blog/2174405/202308/2174405-20230814214634231-903997386.png
[-]: https://www.zhihu.com/question/63375062
[image-20221116161829987]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/56172721e2ba4ca88842a29864040fd5.png
[image-20221116161829987 1]: https://img2023.cnblogs.com/blog/2174405/202308/2174405-20230814214633964-641139754.png
[image-20220701111109352]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/167491ef820b49e5b12e02f7fbd9b297.png
[image-20220701111109352 1]: https://img2023.cnblogs.com/blog/2174405/202308/2174405-20230814214634028-1444273090.png
[image-20230814175148317]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/8a3056d3d7e14938a3bead8e13acb74b.png
[image-20230814175148317 1]: https://img2023.cnblogs.com/blog/2174405/202308/2174405-20230814214634242-128243443.png
[image-20221116170053352]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/cdfcbba2248e49cfb35a60048f62b690.png
[image-20221116170053352 1]: https://img2023.cnblogs.com/blog/2174405/202308/2174405-20230814214633866-796170140.png
[image-20230814182948555]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/b2905b1c8a3144809e233166c76926f3.png
[image-20230814182948555 1]: https://img2023.cnblogs.com/blog/2174405/202308/2174405-20230814214634025-1115556577.png
[image-20230814190446420]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/54ca80148532438c9476e75a6b24d4c2.png
[image-20230814190446420 1]: https://img2023.cnblogs.com/blog/2174405/202308/2174405-20230814214634182-56452591.png
[image-20230814195648180]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/b8dd113d161f40618bad751184fa0fbf.png
[image-20230814195648180 1]: https://img2023.cnblogs.com/blog/2174405/202308/2174405-20230814214634312-1164550499.png
[2623804d6ab5408c2e5605d9433356e7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/a18958e8fd7447a091f3cde4c06a1fc1.png
[2623804d6ab5408c2e5605d9433356e7.png 1]: https://img2023.cnblogs.com/blog/2174405/202308/2174405-20230814214634394-693472761.png
[image-20230814201353059]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/f6004d1b5c2d46fc9fd663508afae9a9.png
[image-20230814201353059 1]: https://img2023.cnblogs.com/blog/2174405/202308/2174405-20230814214634085-66520765.png
[easy]: https://pdos.csail.mit.edu/6.828/2022/labs/guidance.html