从零开始写 OS 内核 - 虚拟内存初探

系列目录

• 序篇
• 准备工作
• BIOS 启动到实模式
• GDT 与保护模式
• 虚拟内存初探
• 加载并进入 kernel
• 显示与打印
• 全局描述符表 GDT
• 中断处理
• 虚拟内存完善
• 实现堆和 malloc
• 第一个 kernel 线程
• 多线程切换
• 锁与多线程同步
• 进入用户态
• 进程的实现
• 系统调用
• 简单的文件系统
• 加载可执行程序
• 键盘驱动
• 运行 shell

kernel 虚拟内存概览

接上一篇 GDT 与保护模式，这一篇将是 loader 的重点。首先我们需要建立 kernel 空间的虚拟内存。如果你对虚拟内存的原理还不熟悉，请务必先自学，这里可以提供一个文档供参考。

到目前为止我们始终在物理内存上操作，确切地说是在 1MB 的低地址空间内操作，这一切都很简单直接。但是接下来 loader 即将为加载 kernel 做准备，我们需要在更广阔的 4GB 虚拟内存空间上规划数据和代码。

仿照 Linux 系统，我们将使用 3GB 以上的高地址空间作为内核空间来开展后续所有工作。例如最基本的，目前的物理低地址 1MB 会被映射到 virtual 地址 0 ~ 1MB 以及 3GB 以上空间 0xC0000000 ~ (0xC0000000 + 1MB) 处：

进入 kernel 以后，对低 1MB 空间的访问将会使用 0xC0000000 ~ (0xC0000000 + 1MB) 虚拟地址，这里主要包括当前使用的 stack，以及显示器对应的内存映射：

所以 video 内存基地址将从 virtual 地址 0xC00B8000 开始，不过目前不必深究，后续将会在显示与打印一篇中详解。

---

除了最基本的低 1MB 内存空间，loader 还需要进一步在 0xC0000000 以上的 virtual 空间中开疆拓土，这主要包括两部分：

• kernel 所使用的页目录（page directory）和页表（page table）；
• kernel 二进制镜像的读取，以及代码、数据的加载；

下面给出整个 loader 阶段将要搭建的 virtual-to-physical 内存映射关系图：

这张图是本篇最重要的全局图，其中第二行是第一行经过“扭曲”比例的图示，我们将 3GB 以下的用户空间缩小显示，当前重点只关注 3GB 以上的内核空间（粗框部分）。由于是 virtual 地址空间，我们的空间划分可以比较随意和“奢侈”，我们以 4MB 为单位，从 0xC0000000 开始在 virtual 空间切割划分出以下几个区域：

• 第一个 4MB 保留，其中低 1MB 空间映射到了 physical 地址的低 1MB，这是上面已经解释过的；
• 第二个 4MB（橙色）用来映射 kernel 的所有 page tables；
• 第三个 4MB（绿色），即从 0xC0800000开始，作为加载、存放 kernel 代码和数据的空间，也就是说 kernel 从该处开始编址；

这里要说一句，实现一个 OS 并没有固定的方式，以上只是我个人的实现方式。实际上对于内存的规划是很灵活的，就像这个项目的名字 scroll 一样，内存就是一幅画卷，CPU 则是画笔，在遵循一定规则的前提下，可以做自由发挥。

下面我们首先开始橙色部分，即内核 page directory 和 page tables 的建立。

建立 kernel 虚拟内存

在开始这一段之前，我们还是回顾一下页目录（page directory）和页表（page table）的相关原理。

有一些关键数字需要记住：

• 页（page）的大小为 4096；
• 页目录项 pde (page directory entry) 和页表项 pte (page table entry)，本质上是一样的结构，大小为 4 bytes；
• page direcotry 一共有 1024 项，指向总共 1024 张 page table，一共 4MB；
• 每个 page table 都有 1024 项，指向 1024 张 pages，管理着 1024 * 4KB = 4MB 的 virtual 空间；
• 所以每个 pde 管理着 4MB 的 virtual 空间；

---

好了，下面我们开始建立 kernel 空间的页表。按照惯例给出代码链接：这一部分相关的代码从函数 setup_page 开始，供你参考。

从这里开始以下，按照术语惯例，virtual 页我将用 page 表述，而 physical 页将用 frame 来表述。

建立 page directory

首先我们需要拿出一个 frame，用来作为 page directory。回到 physical 内存分布的那张图，目前 1MB 以下的部分已被占用，我们可以使用的部分就从 1MB 即 0x100000 开始。

我选择的是 0x100000 + 4KB，即 0x100000 后的第 2 个 frame 作为 page directory，当然这完全是个人选择；0x100000 后的第 1 个 frame 我选择将它作为第一个 page table：

再次强调，这是我的个人选择；frame 的选择是非常自由的，只要是还没被占用的都可以使用，当然了你要记住自己用过了哪些 frames，合理紧凑并且尽量“美观”地规划使用。

映射 1MB 低内存空间

值得注意的是，第 0 和第 768 个 pde 都指向了同一个 page table，这个 page table 我们将用它映射 0 ～ 1MB 低内存，即我们目前所处的 1MB 内存空间。当然这个 page table 可以管理 4MB 的空间，我们只映射了其中的 1MB，剩余 3MB 的 virtual 空间就闲置了，不过这没有关系，闲置就闲置，反正这是 virtual 空间。

下图展示了低 1MB 内存在页表中被映射的方式：

pde[0] 管理的是 virtual 空间最低的 4MB，其中的起始 1MB，被映射到了 physical 的低 1MB 上，这是一一对应的映射，virtual 地址完全等于 physical 地址，这样在打开 paging 之后，我们对 1MB 低内存的访问变为使用 virtual 地址，和之前的 physical 地址访问一样，不会感知到任何变化。

pde[768] 管理的是 0xC0000000 即 3GB 开始的第一个 4MB 空间，回到本篇开始的第一张图，其起始的 1MB 也被映射到低 1MB 内存上。在打开 paging 并进入 kernel 后，我们将使用 0xC0000000 ～0xC0000000 + 1MB 的空间访问低 1MB 内存：

映射 page directory 以及 page tables 本身

这里是本节的重点和难点。我们知道 page directory 和 page tables 所指向的都是 physical 页，而一旦打开了 paging 模式，我们以后所有对内存的访问将全部通过 virtual 地址，无法再直接操作 physical 地址。那么问题来了，我们如何访问并修改 page directory 和 page tables 本身呢？

一种方法当然是在需要时关闭 paging，直接访问 physical 地址，之前推荐的教程 JamesM's kernel development tutorials 在很多地方都是这么做的，不过这并不是一种好的做法，原因有以下几点：

• 进入复杂的 kernel 以后，代码的执行会大量涉及到 stack 和 heap，以及其他全局变量等内存访问，这些全部都是 kernel 空间的 virtual 地址，如果此时突然关闭 paging，对它们的访问将无法进行。你必须非常小心地安排你的代码对内存的访问，否则将会出现不可预知的后果，但是这其实非常难做到；
• 一旦开启多线程，如果在关闭 paging 的情况下发生了中断，CPU 将进行一些自动的 stack 操作以及中断处理，全部都是对 virtual 地址的操作，显然其结果也是灾难性的；

一个更合理的做法是，我们将 page directory 和 page tables 本身也映射到 virtual 空间，这样就可以像访问其他正常内存一样访问它们。从本质上说 page directory 和 page tables 无非也是一些 page，完全可以和其它内存访问一视同仁。问题就是，应该如何建立这种映射？来看下图：

我们将 pde[769] 指向了 page directory 这个 frame 本身。这样 page direcotry 实际上同时也充当了一个 page table，它所管理的正好是 1024 张 page tables 本身，一共 4MB。这 1024 张 page tables，其中有一张就是 page direcotry 它自己。

是不是有点绕？换言之，由于 pde[769] 指向了 page directory 它自己，因此 0xC0400000 ～ 0xC0800000 这 4MB 的 virtual 空间，现在被映射到了 1024 张 page tables 上，而且更好的是，它们的 virtual 地址是完全连续地，紧密地排布在这 4MB 空间里。

由此，上面的问题已经解决，page tables 对应的 virtual 地址空间为：

0xC0400000 ~ 0xC0800000

这是 4GB 空间中第 769 个 4MB 空间 （总共 1024 个 4MB 空间，组成 4GB）。

并且我们同时还得到了 page directory 它自己的 virtual 地址为：

0xC0701000

即 0xC0400000 ～ 0xC0800000 这 4MB 空间中的第 769 个 page，是不是很巧妙：)

---

这里的核心思想是，page directory 其实本质上是一个特殊的 page table，它和其它 page table 一样，都管理着 4MB 的空间。

如果感觉还是有点绕的话，你不妨反过来验证一下，从上面给出的 virtual 地址开始，推导实际指向的 physical 地址是哪里，我想很快就能理清这里面的逻辑。

如果你进一步思考的话，就会发现这并不是唯一的实现方式。你完全可以不选择 pde[769]，而使用其它 virtual 空间来映射 page tables，例如用 pde[770] 也可以，这样所有 page tables 对应的 virtual 空间就变成了 0xC0800000 ～ 0xC0C00000。用 pde[769] 只是我个人的选择，因为它是 0xC0000000 后的第二个 4MB 空间，这样的安排，virtual 空间的使用能比较紧凑整齐一点。

映射 kernel 空间的其它区域

到目前为止，pde 768 和 769 已经被使用，即 0xC0000000 ~ 0xC0400000 和 0xC0400000 ~ 0xC0800000 这两块 4MB 空间已被征用。剩下的 pde[770] ～ pde[1023] 对应的 254 个 page tables，我们依次为它们安排上 frames。这样我们最终征用了 256 个 pages & frames，总共 1MB 的内存（virtual & physical），来建立 kernel 空间（3GB ～ 4GB）的 page tables，管理这 1GB 的空间。

我们将本章开始的那个 virtual-to-physical 内存映射关系图中的橙色部分抽出放大，展示 kernel 的 256 张 page tables 的内存分布：

注意到我们只分配了 kernel 空间即 3GB 以上的 page tables，共 256 张，占地 1MB，它们映射的也是 0xC0400000 ~ 0xC0800000 空间的后 1/4 部分即 0xC0700000 ~ 0xC0800000；而 3GB 以下的用户空间此时并没有分配 page tables，因为目前我们并没有使用到。

这 256 张 kernel 页表（其中有一张是 page directory 本身），是我们编写 kernel 期间最核心的 page tables，并且在 page directory 里建立了 pde[768] ~ pde[1023] 这全部的 256 个表项，指向了这些 page tables。

其实除了前两个 page table，后面 254 个目前都是空的，没有被用到，我们只是为它们安排好了 frame 而已。这里用去了足足 1MB 的 physical 内存，这看上有点奢侈了，毕竟这个项目配置里 physical 内存总共只有 32 MB（见 bochsrc.txt，当然现在的计算机内存远不止 32 MB，这已经不是个问题）。这样做有一个非常重要的原因，那就是这 256 张 kernel page tables 后面将被所有的进程（process）共享，也就是说对于用户 process 而言，3GB 以下的空间是隔离的，而 3GB 以上的 kernel 的空间是共享的，这也是理所当然的，否则就有多个 kernel 在内存中独立运行了。

每次 fork 出一个新的 process，它的 page directory 的后 1/4 即 768 ～ 1023 项将会直接复制 kernel 的 page directory 的 768 ～ 1023 项，共同指向这 256 张 kernel page tables。所以我们要求这 256 张 page tables 对应的 frames 从一开始就固定下来，后面也不再变化，这样才能实现所有 process 共享的效果。

打开 paging

page tables 都准备就绪以后，就可以打开 paging 了：

enable_page:
  sgdt [gdt_ptr]

  ; move the video segment to > 0xC0000000
  mov ebx, [gdt_ptr + 2]
  or dword [ebx + 0x18 + 4], 0xC0000000

  ; move gdt to > 0xC0000000
  add dword [gdt_ptr + 2], 0xC0000000

  ; move stack to > 0xC0000000
  mov eax, [esp]
  add esp, 0xc0000000
  mov [esp], eax

  ; set page directory address to cr3 register 
  mov eax, PAGE_DIR_PHYSICAL_ADDR
  mov cr3, eax
  
  ; enable paging on cr0 register
  mov eax, cr0
  or eax, 0x80000000
  mov cr0, eax

这里最重要的就是设置 CR3 寄存器，使之指向 page directory 的 frame （注意是 physical 地址），然后打开 CR0 寄存器上的 paging 比特位开关。

总结

至此，loader 阶段关于 kernel 虚拟内存初始化的部分就结束了。这一段的代码并不长，核心仅仅是 setup_page 这一个函数，但是其背后的原理却是非常深刻复杂。在 loader 阶段初步建立起 virtual memory 的框架，这对后面进入 kernel 之后的内存管理打下了良好的基础。

在当前阶段我们所有的 virtual-to-physical 的内存分配和映射都是提前规划，预先分配再使用的，每一块 physical frame 都是手动安排。这其实并没有完全发挥出 virtual memory 的作用。在后面进入 kernel 之后，我们将进一步完善 virtual memory 相关的工作，这将包括缺页异常 (page fault)的处理，进程 page directory 的复制等。

virtual memory 的处理是贯穿 kernel 实现和运行的底层核心工作，必须保证绝对的正确和稳定。一旦出错，系统会立刻出现各种难以预知的奇怪错误甚至崩溃，并且 debug 非常困难。

下一篇我们将会加载真正的 kernel 到内存并且转到 kernel 开始执行代码，这将是进入 kernel 前的最后一道关卡。