xv6部分源码阅读-1

xv6部分源码阅读

前言

在lab2中，我们会为了完成attack这个实验，而花费大量的时间去阅读相关的系统调用源码，以此来分析出我们最终secret所在的页表的位置，而我写lab2中，重点并没有关注其中的逻辑关系，有很多想仔细分析的函数都没有深入地去看，故写此文，以便理解记忆。

proc

要想搞清楚proc所分配的页表，首先，还得了解我们的proc是什么样子的：

// 每个进程的状态
struct proc {struct spinlock lock;       // 保护进程状态的锁// 在使用以下字段时必须持有 p->lock 锁：enum procstate state;        // 进程的当前状态void *chan;                  // 如果非零，表示进程正在 chan 上睡眠int killed;                  // 如果非零，表示该进程已经被杀死int xstate;                  // 进程退出时返回给父进程的退出状态int pid;                     // 进程 IDint tracing;                 // 跟踪系统调用的掩码// 必须持有 wait_lock 锁才能使用以下字段：struct proc *parent;         // 父进程// 这些字段是进程私有的，因此不需要持有 p->lock 锁：uint64 kstack;               // 内核栈的虚拟地址uint64 sz;                   // 进程内存大小（字节数）pagetable_t pagetable;       // 用户页表struct trapframe *trapframe; // trampoline.S 中使用的数据页面struct context context;      // 切换到该进程时的上下文struct file *ofile[NOFILE];  // 打开的文件struct inode *cwd;           // 当前工作目录char name[16];               // 进程名称（用于调试）
};

我们的重点便是下半部分，kstack就是我们的内核栈的虚拟地址的指针，当我们进程需要执行系统调用的时候，我们首先会通过trampoline保存我们的上下文数据(寄存器中的数据)，保存到哪？每一个proc都有可能执行系统调用，所以不能将他们存放在同一个地方，所以，我们的proc结构体还维护了一个trapframe字段，用来我保存我们在执行系统调用之前的上下文，以便于返回时恢复状态，我们可以在trampoline.S里面轻易地看见，保存上下文的代码：

  ....sd ra, 40(a0) sd sp, 48(a0) sd gp, 56(a0)sd tp, 64(a0) sd t0, 72(a0) .....

其中的a0，表示我们的trapframe的地址，ra/sp等表示我们执行系统调用之前的寄存器，这就表示将这些寄存器保存到我们的trapframe中，他作为一个单独的页表分配，而在返回的时候恢复上下文的代码，我们也可以在trampoline.S中找到：

  ...ld ra, 40(a0)ld sp, 48(a0)ld gp, 56(a0)  ld tp, 64(a0) ld t0, 72(a0) ...

这就表示从trapframe中获取信息，并赋予寄存器。

在这里我们可以重新理一下之前做过的lab2，刚开始，可能很多人都对trapframe和trampoline不是很理解，实际上，trapframe就是我们需要开辟的新空间，为我们进程保存上下文，恢复上下文服务的，而trampoline是我们所有的进程通过用户页表映射到同一个地方，公共的部分，所有的用户页表都会映射到这个位置，而我们的三级页表实际上也需要分配一个页表来将我们的trampoline和trapframe映射到真正的物理地址上面，最终，我们的proc是如下的映射结构：

VPN2[511]└── VPN1[511]└── VPN0├── [511] → trampoline└── [510] → trapframe

VPN2是我们根页表，也就是最开始创建的页表，随后调用mappages的时候，就会自动创建二级页表，自动创建三级页表(最开始只有VPN2)，然后才能建立我们的映射关系。

所以这里的proc_pagetable一共创建了三个页表，也就可以解释了。

exec

这也是一个相当有趣且复杂的系统调用，我在做lab的时候，没有看见需要去阅读源码的准备工作，所以最开始就给没看，写起lab来也是很吃力的，在exec是exec之前，首先，他是一个系统调用，我们可以在syscall.c里面找到所有syscall的入口：

void
syscall(void)
{int num;struct proc *p = myproc();  // 获取当前进程结构体指针num = p->trapframe->a7;  // 获取系统调用号（存储在 trapframe 的 a7 寄存器中）// 检查系统调用号是否在有效范围内，且是否有对应的系统调用函数if(num > 0 && num < NELEM(syscalls) && syscalls[num]) {// 根据系统调用号 `num` 查找对应的系统调用函数，并调用它//这里的syscall[num]就是直接调用了系统调用的函数。// 将返回值存储在进程的 trapframe 中的 a0 寄存器中p->trapframe->a0 = syscalls[num]();  // 如果进程启用了系统调用追踪功能，打印系统调用的详细信息if ((p->tracing >> num) & 1) {printf("%d: syscall %s -> %ld\n", p->pid, syscall_str[num], p->trapframe->a0);}} else {// 如果系统调用号无效或没有对应的系统调用函数，输出错误信息// 并将返回值设置为 -1printf("%d %s: unknown sys call %d\n", p->pid, p->name, num);p->trapframe->a0 = -1;}
}

我们知道，这里的syscalls数组实际上就是各个系统调用的函数的指针，所以我们通过他，就可以进入到我们的sys_exec了，接下来，就是关于他的代码，而想要去理解这个exec，就得明白，他是干什么的，exec事实上，在lab1里面也见识了很多次

首先是我们执行exec系统调用的入口：

uint64
sys_exec(void)
{char path[MAXPATH], *argv[MAXARG];int i;uint64 uargv, uarg;// 获取传入的参数：参数 1 是用户空间的 argv 地址argaddr(1, &uargv);// 获取程序路径if (argstr(0, path, MAXPATH) < 0) {return -1;  // 如果路径获取失败，返回 -1}memset(argv, 0, sizeof(argv));  // 初始化 argv 数组// 从用户空间获取 argv 数组for (i = 0;; i++) {if (i >= NELEM(argv)) {goto bad;}// 获取用户空间中每个参数的地址if (fetchaddr(uargv + sizeof(uint64) * i, (uint64*)&uarg) < 0) {goto bad; }// 如果参数为 0，表示 argv 数组结束if (uarg == 0) {argv[i] = 0;break;}// 为 argv[i] 分配内存argv[i] = kalloc();if (argv[i] == 0)goto bad;// 获取用户空间中字符串并复制到内核空间if (fetchstr(uarg, argv[i], PGSIZE) < 0)goto bad;}// 此处是真正的执行exec函数，加载指定的程序//下面我们会详细介绍int ret = exec(path, argv);// 释放 argv 数组中分配的内存for (i = 0; i < NELEM(argv) && argv[i] != 0; i++)kfree(argv[i]);return ret;  // 返回 exec 的返回值，成功则为 0，失败则为 -1
bad:// 如果有任何错误发生，释放所有已分配的内存for (i = 0; i < NELEM(argv) && argv[i] != 0; i++)kfree(argv[i]);return -1;  // 返回 -1 表示执行失败
}

我们可以看见，我们系统调用的入口做了一系列的准备工作，然后执行了exec之后，从内核态返回，这里返回就不是执行原来的程序了，而是执行我们在exec中加载的程序！当然，前提是exec执行成功了。

随后，我们可以来看看我们的exec到底干了什么，首先，我们的exec在最开始初始化了一大堆值，我们目前先不关心他，我们要知道，在最开始，我们的exec调用了

  begin_op();

这个函数，有啥用？事实上，每一个文件操作之前，前面都会跟上一个begin_up，下面是他的具体实现：

void begin_op(void)
{// 获取日志锁，确保对日志操作的独占访问acquire(&log.lock);// 循环直到可以开始新的文件系统操作while(1) {// 如果当前日志正在提交，等待提交完成if (log.committing) {// 当前日志正在提交，休眠并等待提交完成sleep(&log, &log.lock);} // 如果当前操作可能会超出日志的空间，等待日志提交else if (log.lh.n + (log.outstanding + 1) * MAXOPBLOCKS > LOGSIZE) {// 当前操作可能耗尽日志空间，休眠并等待提交sleep(&log, &log.lock);} else {// 当前操作可以进行，增加待处理操作的计数log.outstanding += 1;// 释放日志锁，允许其他线程访问日志release(&log.lock);// 成功开始文件系统操作，跳出循环break;}}
}

我们可以看到，事实上，这就是一个加上一个锁的操作，而是通过日志加锁，来保证每个文件操对日志操作的原子性，顺序性，但是这里竟然是全局锁，哈人。通过加这样一个锁，我们对日志的操作就实现了原子性，随后，我们会从文件系统中寻找我们需要执行的系统调用：

  if((ip = namei(path)) == 0){end_op();return -1;}ilock(ip);

ilock实际上就是锁定该文件，防止其他进程修改

随后，我们需要读取这个文件，然后对这个文件进行一些验证，随后分配空间，在这里需要注意，trapframe依旧是旧的，之后会进行更改：

  // 从 inode 所代表的文件中读取 ELF 头部（ELF Header）到 elf 结构体中// 参数含义：//   ip：表示打开的文件 inode//   0：表示这是从用户空间发起的（传 0）//   (uint64)&elf：读取到内存 elf 的地址//   0：从文件开头开始读//   sizeof(elf)：读取字节数等于 ELF 头的大小if(readi(ip, 0, (uint64)&elf, 0, sizeof(elf)) != sizeof(elf))goto bad;  // 如果读取失败或读取长度不足，则跳转到错误处理// 检查读取到的 ELF 文件头的魔数是否匹配// ELF_MAGIC 是一个特定的常数（0x464C457F），用来判断文件是否为 ELF 格式if(elf.magic != ELF_MAGIC)goto bad;  // 如果不是 ELF 文件，即魔数不对，跳转到错误处理// 为当前进程 p 创建一个新的用户页表// 旧的页表包含的是之前进程的地址空间，现在要执行新程序，因此需要一个全新的页表// 这里会映射trampoline和trapframe，但是trapframe在之后会进行更新。if((pagetable = proc_pagetable(p)) == 0)goto bad;  // 分配失败时跳转到错误处理

之后，还会进行一系列验证，最终，会将我们的elf文件的段数据写入内存，总体验证过程和流程如下：

for(i=0, off=elf.phoff; i<elf.phnum; i++, off+=sizeof(ph)){// 从 ELF 文件中读取每个程序头（Program Header）到 ph 结构体if(readi(ip, 0, (uint64)&ph, off, sizeof(ph)) != sizeof(ph))goto bad;// 如果程序头的类型不是 ELF_PROG_LOAD（表示可加载的程序段），跳过当前程序头if(ph.type != ELF_PROG_LOAD)continue;// 程序段的内存大小必须大于或等于文件大小，否则不合法，跳转到错误处理if(ph.memsz < ph.filesz)goto bad;// 如果程序段的结束地址小于起始地址，说明程序头出错，跳转到错误处理if(ph.vaddr + ph.memsz < ph.vaddr)goto bad;// 程序段的起始地址必须是页面大小对齐的，否则跳转到错误处理if(ph.vaddr % PGSIZE != 0)goto bad;// 为程序段分配内存，确保分配的内存区域是连续的，并且不会与其他程序段冲突uint64 sz1;if((sz1 = uvmalloc(pagetable, sz, ph.vaddr + ph.memsz, flags2perm(ph.flags))) == 0)goto bad;sz = sz1;// 将 ELF 程序段的数据加载到内存中if(loadseg(pagetable, ph.vaddr, ip, ph.off, ph.filesz) < 0)goto bad;
}

一旦发现错误，就会立刻跳转到错误处理的地方，而最后，我们会将loadseg加载到页表中：

static int
loadseg(pagetable_t pagetable, uint64 va, struct inode *ip, uint offset, uint sz)
{uint i, n;uint64 pa;// 遍历程序段的每一页（PGSIZE大致为4KB）for(i = 0; i < sz; i += PGSIZE){// 获取当前虚拟地址（va + i）对应的物理地址pa = walkaddr(pagetable, va + i);// 如果无法找到对应的物理地址，发生错误if(pa == 0)panic("loadseg: address should exist");// 判断当前页是否是最后一页，如果是，则计算实际读取的大小if(sz - i < PGSIZE)n = sz - i;elsen = PGSIZE;// 从文件（inode）中读取数据到物理地址 pa 上if(readi(ip, 0, (uint64)pa, offset+i, n) != n)return -1;  // 如果读取失败，返回错误}return 0;  // 成功加载所有数据
}

实际上，loadseg对于我们并不是过于重要，我们只需要知道，他会将我们给的段写入到单独的内存页，这样就行了。

那么，将段单独写入内存页的逻辑在哪？其实我们已经见识过了：

for(i=0, off=elf.phoff; i<elf.phnum; i++, off+=sizeof(ph))

这里的for循环，就是将我们的程序段循环遍历的地方，通过这样，我们可以将符合要求的段加入我们的页表中，即便我们不知道有多少个段，我们也可以加一个printf语句来帮助我们判断，从而弄清楚到底分配了几个页。

至此，我们就搞清楚了我们的页表是如何分配的了

但是，到目前为止，我们仅仅是将我们的页表给分配了，并且将我们的段都写入进去了，我们还需要分配我们的栈空间。

  // 将当前地址 sz 向上对齐到页边界，为用户栈分配内存页（至少 USERSTACK + 1 页）// 第一页作为 "栈保护页"，不可访问；剩下的 USERSTACK 页是实际的用户栈sz = PGROUNDUP(sz);  // 保证下一次页分配是对齐的uint64 sz1;if((sz1 = uvmalloc(pagetable, sz, sz + (USERSTACK+1)*PGSIZE, PTE_W)) == 0)goto bad; // 分配失败，跳转错误处理sz = sz1;// 清除栈底的 guard 页，即使映射存在也让它不可访问（trap）uvmclear(pagetable, sz-(USERSTACK+1)*PGSIZE);// 设置 sp（栈指针）和 stackbase（栈底，栈增长不会低于这里）sp = sz; // 初始 sp 指向用户栈顶部stackbase = sp - USERSTACK*PGSIZE; // 栈的最低地址（不包括 guard 页）

当然，我们可以看见除了我们的栈空间，还分配了栈保护页，这是为了防止栈溢出是将其他区域的数据覆盖掉所设置的，当发生栈溢出，访问到保护页的时候，系统就会触发异常。

随后需要初始化我们的栈

// 将命令行参数字符串逐个压入用户栈，同时构建一个 ustack[] 数组，
// 存放每个参数字符串在用户栈中的地址（即 argv[i] 的指针）。
for(argc = 0; argv[argc]; argc++) {// 超出限度，就转到错误处理if(argc >= MAXARG)goto bad;// 给这个参数字符串分配空间，长度需要加上结尾的 '\0'sp -= strlen(argv[argc]) + 1;// 内存对齐sp -= sp % 16;// 如果当前栈指针已经低于栈底，说明栈空间不够，返回错误if(sp < stackbase)goto bad;// 把参数字符串从内核拷贝到用户页表的栈空间（虚拟地址为 sp）if(copyout(pagetable, sp, argv[argc], strlen(argv[argc]) + 1) < 0)goto bad;// 将我们每个参数的指针放在数组里面。ustack[argc] = sp;
}
// 添加 NULL 结尾，相当于 argv[argc] = 0，表示参数结束
ustack[argc] = 0;

可以看见，我们主要将我们的参数通过sp拷贝到用户的栈空间中，并且初始化了一个ustack数组来存储这些sp指针，他在之后会显现他的作用：

// 这里是为我们需要拷贝的数据腾出栈空间
// 所以需要改变指针栈指针sp -= (argc+1) * sizeof(uint64);
// 内存对齐sp -= sp % 16;if(sp < stackbase)goto bad;
// 将我们的ustack数组的指针数组拷贝到栈空间中，我们之后便能通过ustack中存储的sp指针
// 去找到对应的参数if(copyout(pagetable, sp, (char *)ustack, (argc+1)*sizeof(uint64)) < 0)goto bad;

综上，我们将ustack拷贝到栈空间，随后我们就可以轻易地通过这个数组存储的指针，访问到相对应的参数了，为啥要通过ustack访问？这是为了保证我们栈访问的安全性，统一性。

最后，便是我们的收尾工作了，我们的exec真的要结束了：

// 将栈指针 (sp) 保存到 trapframe 的 a1 寄存器。
// 这个栈指针将在用户程序中使用，'sp' 指向用户栈。
p->trapframe->a1 = sp;// 保存程序名以便调试。
// 从完整路径中提取程序名（即最后一个 '/' 后的部分）。
for(last = s = path; *s; s++)if (*s == '/')          // 查找路径中的最后一个 '/'last = s + 1;       // 程序名从 '/' 后开始
safestrcpy(p->name, last, sizeof(p->name));  // 将程序名复制到进程名称中，方便调试// 提交新的用户空间镜像，通过切换页表和更新进程状态来完成。
// 保存当前的（旧的）页表
oldpagetable = p->pagetable;
// 设置新的页表
p->pagetable = pagetable;
// 更新进程的大小
p->sz = sz;
// 设置进程的初始程序计数器（epc）为 ELF 文件的入口点
p->trapframe->epc = elf.entry;  // 初始程序计数器 = main 函数的地址
// 设置栈指针（sp）为用户空间的栈指针
p->trapframe->sp = sp; // 初始栈指针
// 释放旧的页表资源
proc_freepagetable(oldpagetable, oldsz);

我们这里主要是将栈指针的起始位置存入我们的trapframe，a0保存的是我们的系统调用号，而a1则是我们的参数列表的栈指针。这一步已经完成了，最后的，那就是我们的首位工作，将各个参数更新，除此之外，还需要将我们的旧的页表给释放掉，值得注意的是，我们这里替换的页表实际上是用户态的页表，而当前的代码是在内核态中执行的，所以我们的exec不会受到用户态的替换页表的影响。

系统调用到底干了啥？

另外讲点有意思的，我们之前提过无数次用户态和内核态，我们的用户态通过执行系统调用，就会跳转到内核态，那么到底是怎么跳转的？我们现在就来解决这个问题：

在我们执行系统调用的时候，实际上，在用户态代码中，我们的这些调用都会在user.h中声明，在编译之后，usys.S会通过usys.pl这个脚本去生成出来，这样，就实现了我们在用户态执行系统调用的跳转的汇编代码，举个例子，比如说exec：

exec:li a7, SYS_exececallret
.global open

我们将SYS_exec存入a7这个寄存器中，SYS_exec是啥？事实上，在我们的lab2中应该已经能够知道，SYS_exec就是在kernel/syscall.h中定义的一个常量，而这里也确实引入了这样一个头文件，所以，这里是直接存入了我们的系统调用编号，方便调用的！

然后调用ecall，会跳转到我们的内核指定的位置，也就是stvec寄存器指向的位置，在哪里指定的？当然是在初始化我们的xv6的时候指定的，我们可以在trap.c中找到通过调用函数来设置stvec的函数w_stvec，其内部是这样的：

w_stvec(uint64 x)
{asm volatile("csrw stvec, %0" : : "r" (x));
}

通过这个函数，我们可以动态的修改我们的stvec，因为我们的ecall不仅有可能在用户态执行，还可能在内核态执行，所以通过这种方式，当我们从usertrap中返回的时候，我们就会把这个cpu的stvec寄存器设置成用户产生中断的处理位置，这样，就可以让我们的ecall跳转到正确的位置。

此时我们是在用户态中调用的ecall，所以应该是跳转到trampoline.S中的uservec代码段中，如下：

.globl uservec
uservec:    # 保存用户空间传入的 a0 寄存器值到 sscratch 寄存器，# 因为 a0 会用于获取 TRAPFRAME 地址。csrw sscratch, a0# 设置 a0 为 TRAPFRAME 的地址，# 每个进程都有一个单独的 trapframe 内存区域，# 但是在每个进程的用户页表中，该区域被映射到相同的虚拟地址。li a0, TRAPFRAME...#此处省略很多行保存寄存器逻辑# 将之前保存的用户空间的 a0 值（即 TRAPFRAME 的地址）重新保存到 p->trapframe->a0。csrr t0, sscratchsd t0, 112(a0)# 从 p->trapframe->kernel_sp 加载内核栈指针，并设置 sp。ld sp, 8(a0)# 从 p->trapframe->kernel_hartid 加载当前的 hartid，设置 tp。ld tp, 32(a0)# 从 p->trapframe->kernel_trap 加载 usertrap 函数的地址，并跳转到 usertrap。ld t0, 16(a0)# 从 p->trapframe->kernel_satp 获取内核页表地址，设置 satp 寄存器。ld t1, 0(a0)# 等待先前的内存操作完成，以便后续的操作使用用户页表。sfence.vma zero, zero# 安装内核页表（切换到内核页表）。csrw satp, t1# 刷新 TLB 缓存，移除过时的用户页表条目。sfence.vma zero, zero# 跳转到 usertrap 函数，该函数不会返回。jr t0

可以看见，通过一系列相关操作，我们就会跳转到usertrap(C语言函数)中，而usertrap就是进入到syscall之前需要做的准备工作，但是此时已经真正的进入内核态了！

下面来看看我们的usertrap究竟是什么个事

// 处理来自用户态的中断、异常或系统调用。
// 被 trampoline.S 中的 uservec 调用。
void
usertrap(void)
{int which_dev = 0;// 检查是否真的是从用户态陷入内核的。// 如果 SPP（Supervisor Previous Privilege）不为 0，说明不是从用户态过来的，出错。if((r_sstatus() & SSTATUS_SPP) != 0)panic("usertrap: not from user mode");// 设置 stvec 为内核态的中断向量 kernelvec，表示从现在开始内核态中断交由 kernelvec 处理// 这是为了防止在内核执行期间再次陷入时，还用的是用户态的 uservec。w_stvec((uint64)kernelvec);// 获取当前运行的进程struct proc *p = myproc();// 保存当前触发 trap 时的 PC（sepc 存储的是触发 trap 的用户态地址）p->trapframe->epc = r_sepc();// 判断是不是系统调用（scause=8 表示 ecall-from-U-mode）if(r_scause() == 8){// 如果进程已经被标记为 killed，则直接退出if(killed(p))exit(-1);// ecall 指令执行后 sepc 仍然指向 ecall，所以这里 +4 是为了从下一条指令继续执行p->trapframe->epc += 4;// 开中断（因为 syscall 处理期间我们已经不需要再屏蔽中断了）intr_on();// 执行系统调用syscall();} else if((which_dev = devintr()) != 0){// 如果是设备中断（如时钟中断、UART 等），交给 devintr() 处理// 返回值标识具体设备，这里先保存下来以便后续判断是否需要 yield CPU// 如果是设备中断，正常返回；否则下面打印错误信息} else {// 既不是 syscall 也不是设备中断，属于非法中断或异常printf("usertrap(): unexpected scause 0x%lx pid=%d\n", r_scause(), p->pid);printf("            sepc=0x%lx stval=0x%lx\n", r_sepc(), r_stval());// 标记进程为 killed，稍后会终止它setkilled(p);}// 如果此时进程被标记为 killed，就退出if(killed(p))exit(-1);// 如果是时钟中断，就让出 CPU（进行调度）if(which_dev == 2)yield();// 从内核返回用户态（设置好寄存器、trapframe、切换 stvec）usertrapret();
}

每一步相关的说明都已经注释好了，在usertrap中，我们真的会调用一个syscall函数，并且在调用完成之后，真的会调用usertrapret返回到我们的用户态，当然，如果我们执行的是exec系统调用，返回的用户态已经是被替换过的全新的程序，至此，我们已经实现了一个系统调用的闭环。

目前来看，我们已经理解了很多之前不知道的东西，现在，我们来阅读阅读页表课前置要求的一些源码吧！

sbrk/kalloc/mappages

其实最好的阅读方式并不是通过硬啃一个文件，一段源代码能够解决的，关键是流程，我们应该跟着流程来分析，首先是我们在lab2中用到的sbrk，我们可以在syscall.c中找到数组中的sbrk，我们可以通过它跳转到sys_sbrk的函数：

uint64
sys_sbrk(void)
{uint64 addr;int n;argint(0, &n);addr = myproc()->sz;if(growproc(n) < 0)return -1;return addr;
}

这里的argint事实上也是获取参数，然后将我们传入的参数向下传入给growproc函数，而这个函数是干啥的？我们可以仔细来看看这个函数：

int
growproc(int n)
{uint64 sz;struct proc *p = myproc();// 获取当前进程的虚拟内存大小（sz表示进程的堆顶）sz = p->sz;if(n > 0){// 如果 n > 0，表示需要增加内存// 调用 uvmalloc 分配从 sz 到 sz + n 的内存if((sz = uvmalloc(p->pagetable, sz, sz + n, PTE_W)) == 0) {return -1;  // 分配失败，返回 -1}} else if(n < 0){// 如果 n < 0，表示需要减少内存sz = uvmdealloc(p->pagetable, sz, sz + n);  // 释放 sz 到 sz + n 之间的内存}// 更新进程的虚拟内存大小（sz）p->sz = sz;return 0;  // 返回 0 表示成功
}

在这里，我们可以看见至关重要的一个函数，uvmalloc，之前做lab2分析的时候，无论在哪里都可以看见他的身影，虽然我通过注释标出了他的功能，但是我们应该继续往下看，他到底是干了个什么事！

uint64
uvmalloc(pagetable_t pagetable, uint64 oldsz, uint64 newsz, int xperm)
{char *mem;uint64 a;int sz;// 如果新的内存大小小于当前大小，则返回当前大小if(newsz < oldsz)return oldsz;// 将 oldsz 对齐到页边界（上舍入到最接近的页边界）oldsz = PGROUNDUP(oldsz);// 从 oldsz 到 newsz 分配内存，每次分配一个页for(a = oldsz; a < newsz; a += sz){sz = PGSIZE;  // 每次分配一个页面mem = kalloc();  // 分配一个物理页if(mem == 0){// 如果分配失败，释放已经分配的内存并返回 0uvmdealloc(pagetable, a, oldsz);return 0;}
#ifndef LAB_SYSCALL// 如果没有启用 LAB_SYSCALL，清零分配的内存memset(mem, 0, sz);
#endif// 将我们当前分配的内存页到进程的虚拟地址空间if(mappages(pagetable, a, sz, (uint64)mem, PTE_R|PTE_U|xperm) != 0){// 如果映射失败，释放内存并退回kfree(mem);uvmdealloc(pagetable, a, oldsz);return 0;}}// 返回新的内存大小return newsz;
}

很明显，这里uvmalloc主要干了两件事：

1. 分配内存
2. 映射虚拟地址

我们现在有的是时间，便可以好好的看一下kalloc是干了一个什么事，mappages又是在干啥：

// kalloc: 从内核的空闲内存链表中分配一个页面（PGSIZE）。
// 它通过加锁来确保线程安全，并从空闲链表中取出一个空闲的内存块（大小为页面）。
// 如果成功，它将返回该内存块的地址。如果没有空闲内存块，则返回 NULL。
void *kalloc(void)
{struct run *r;// 获取锁，保证访问内存分配器时的线程安全。acquire(&kmem.lock);// 从空闲内存链表中获取一个空闲页面块r = kmem.freelist;// 如果有空闲内存块，更新空闲链表指针if(r) {kmem.freelist = r->next;}// 释放锁release(&kmem.lock);// 如果没有定义 LAB_SYSCALL，则将分配的内存填充为 5（用垃圾数据填充）
#ifndef LAB_SYSCALLif(r)memset((char*)r, 5, PGSIZE); // fill with junk
#endif// 返回分配的内存块地址，类型转换为 void*。return (void*)r;
}

在这里，大多数信息已经通过注释标记好了，在lab2中我们提过，我们xv6的内存是一种栈的形式保存的，事实上，只是一个比喻，而真正的数据结构是链表，我们的kalloc便是同空闲内存链表中获取一块页，这样，而这个去除的规则恰好是符合栈的形式的，值得注意的是，我们的kalloc分配的是物理地址，因此我们需要通过mappages来映射这个物理地址！

那么我们已经知道，我们的页表是如何分配的了，下面就可以看看我们的mappages的逻辑了：

// mappages 函数将从虚拟地址 va 开始的内存区域映射到物理地址 pa 开始的物理内存区域。
// 每个页表项（PTE）对应一个虚拟地址页，perm 参数指定了映射的权限。
// va 和 size 必须是页对齐的，表示映射的虚拟地址和大小都应该是页面大小的整数倍。
// 返回 0 表示成功，返回 -1 表示无法为虚拟地址分配页表页面。int mappages(pagetable_t pagetable, uint64 va, uint64 size, uint64 pa, int perm)
{uint64 a, last;   // a 是当前处理的虚拟地址，last 是最后一个虚拟地址pte_t *pte;        // 页表项指针// 确保虚拟地址 va 和大小 size 都是页对齐的if((va % PGSIZE) != 0)panic("mappages: va not aligned");  // 如果虚拟地址没有页对齐，触发 panicif((size % PGSIZE) != 0)panic("mappages: size not aligned");  // 如果大小没有页对齐，触发 panic// 如果大小为 0，表示没有映射的内容，触发 panicif(size == 0)panic("mappages: size");a = va;              // 当前虚拟地址从 va 开始last = va + size - PGSIZE;  // 计算最后一个需要映射的虚拟地址，确保是页对齐的for(;;) {// 使用 walk 函数获取虚拟地址 a 所对应的页表项（pte），如果页表项没有找到，则分配新的页表项if((pte = walk(pagetable, a, 1)) == 0)return -1;  // 如果无法为当前虚拟地址分配页表项，则返回 -1// 检查该页表项是否已经被映射（即 PTE_V 标志位是否已设置）if(*pte & PTE_V)panic("mappages: remap");  // 如果该页表项已存在映射，触发 panic// 将该页表项的值设置为物理地址 pa 的页表项，并设置权限（perm）和有效位（PTE_V）*pte = PA2PTE(pa) | perm | PTE_V;// 如果当前虚拟地址是最后一个虚拟地址，则退出循环if(a == last)break;a += PGSIZE;  // 移动到下一个虚拟地址（下一个页面）pa += PGSIZE; // 移动到下一个物理地址（下一个页面）}return 0;  // 返回 0 表示映射成功!
}

基本没有什么特别重要的，就是检查各种条件，其中的重点便是walk这个函数，通过walk，去获取我们的虚拟地址，并且在漫步过程中，他会自己创建不存在的页表项(三级页表结构)，这个walk，便是我们映射页表的核心逻辑了，下面是对walk的详细注释：

// 返回页表 pagetable 中对应虚拟地址 va 的 PTE（页表项）的地址。
// 如果 alloc != 0，则在需要时创建缺失的页表页。
//
// RISC-V 的 Sv39 分页方案使用了三级页表。
// 每个页表页包含 512 个 64 位的页表项（PTE）。
// 一个 64 位的虚拟地址被划分为五个字段：
//   位 39..63 —— 必须为零（当前 Sv39 只使用 0~38 位，共 39 位虚拟地址）。
//   位 30..38 —— 9 位，用作第 2 级页表的索引。
//   位 21..29 —— 9 位，用作第 1 级页表的索引。
//   位 12..20 —— 9 位，用作第 0 级页表的索引。
//   位  0..11 —— 12 位，用作页内偏移（即页面内的字节偏移量）。
pte_t *walk(pagetable_t pagetable, uint64 va, int alloc)
{// 如果虚拟地址 va 超出了最大允许的虚拟地址范围，则触发 panicif(va >= MAXVA)panic("walk");// 遍历页表层级，通常有 3 层页表（根页表、二级页表和三级页表）for(int level = 2; level > 0; level--) {// 根据虚拟地址 va 和当前页表层级 level 计算出当前页表项的索引pte_t *pte = &pagetable[PX(level, va)];// 如果该页表项有效（即 PTE_V 标志位为 1），则继续向下遍历if(*pte & PTE_V) {// 获取下一级页表的物理地址，并更新 pagetable 为该页表pagetable = (pagetable_t)PTE2PA(*pte);//这部分可以不用管
//#ifdef LAB_PGTBL
//     // 如果当前页表项是叶子节点（即最后一层页表），则返回该页表项
//      if(PTE_LEAF(*pte)) {
//        return pte;
//      }
#endif} else {// 如果页表项无效，且 alloc 为真，则分配一个新的页表// 如果分配失败，则返回 NULLif(!alloc || (pagetable = (pde_t*)kalloc()) == 0)return 0;// 初始化新分配的页表为零memset(pagetable, 0, PGSIZE);// 将当前页表项的值设置为新分配页表的物理地址，并设置有效位 PTE_V*pte = PA2PTE(pagetable) | PTE_V;}}// 返回当前页表项的指针，该页表项对应的是虚拟地址 va 的最后一级页表项return &pagetable[PX(0, va)];
}

啊啊啊xv6你是一个香香软软的小蛋糕，我们可以看见，我们之前提过很多次的三级页表，终于在这里露出了鸡脚，这里的三个for循环，分别代表每一级的页表，PX(2, va)：提取虚拟地址 va 中的 VPN2 部分的索引，PX(1, va)，提取虚拟地址 va 中的 VPN1 部分的索引，PX(0, va)，提取虚拟地址 va 中的 VPN0 部分的索引。

这里，每一级页表，都会通过kalloc分配一个物理页，但是实际上，最终只有叶子页表上的页表才会映射到我们的物理地址中，其实到这里，还需要再引用一下xv6手册的知识。

kvmmap(*kernel/vm.c*:127)调用mappages(*kernel/vm.c*:138)，mappages将范围虚拟地址到同等范围物理地址的映射装载到一个页表中。它以页面大小为间隔，为范围内的每个虚拟地址单独执行此操作。对于要映射的每个虚拟地址，mappages调用walk来查找该地址的PTE地址。然后，它初始化PTE以保存相关的物理页号、所需权限（PTE_W、PTE_X和/或PTE_R）以及用于标记PTE有效的PTE_V(*kernel/vm.c*:153)。

在查找PTE中的虚拟地址（参见图3.2）时，walk(*kernel/vm.c*:72)模仿RISC-V分页硬件。walk一次从3级页表中获取9个比特位。它使用上一级的9位虚拟地址来查找下一级页表或最终页面的PTE (*kernel/vm.c*:78)。如果PTE无效，则所需的页面还没有分配；如果设置了alloc参数，walk就会分配一个新的页表页面，并将其物理地址放在PTE中。它返回树中最低一级的PTE地址(*kernel/vm.c*:88)。

上面的代码依赖于直接映射到内核虚拟地址空间中的物理内存。例如，当walk降低页表的级别时，它从PTE (*kernel/vm.c*:80)中提取下一级页表的（物理）地址，然后使用该地址作为虚拟地址来获取下一级的PTE (*kernel/vm.c*:78)。

main调用kvminithart (*kernel/vm.c*:53)来安装内核页表。它将根页表页的物理地址写入寄存器satp。之后，CPU将使用内核页表转换地址。由于内核使用标识映射，下一条指令的当前虚拟地址将映射到正确的物理内存地址。

以上为xv6手册中对我们的Walk及其原理相关的介绍，简单来说，walk应该如何去寻找这些页表的索引，其实并不是由我们规定的，而是由硬件规定的这种查询办法，由于我们的cpu在使用虚拟地址的时候，就是采取这种办法去找到对应的物理地址，所以我们的walk也需要采取相同的办法，为什么硬件已经实现了查找功能，但是我们操作系统还需要去实现walk？因为我们最初在操作系统上分配页表，映射页表，是需要操作系统去将他映射到对应的位置的，我觉得这部分是比较难理解的，所以说最好还是去看原文的手册，当然，2020年的课程也有对应的学生提这个问题，可以看看教授是怎么说的。

我们可以看看PX到底是什么

#define PGSHIFT 12
#define PXMASK          0x1FF // 9 bits
#define PXSHIFT(level)  (PGSHIFT+(9*(level)))
#define PX(level, va) ((((uint64) (va)) >> PXSHIFT(level)) & PXMASK)

这里的主要作用，其实就是从虚拟地址va中提取索引值，首先是将其右移层级 * 9 + 12然后与mask相与计算得到9位数字，对应我们之前说过的PTE为9位，返回的就是我们的索引值，然后从这个索引值中找到对应的表项。

并且，在当前找到的表项有效的时候，还会将这个表项的地址左移十位(原因见手册，这里是为了去除标志位)，然后右移12位(同在手册中可见，12位刚好是我们的页表的尺寸，这样就能够腾出offset，表示真正的页表)：

    if(*pte & PTE_V) {pagetable = (pagetable_t)PTE2PA(*pte);

最终，循环结束，我们的最终会得到一个第三级的页表，然后我们在mappages中调用了

    *pte = PA2PTE(pa) | perm | PTE_V;

这是至关重要的一步，我们可以注意到，我们之前的pte基本都是赋值的形式，这是因为，之前都是为了找到我们的地址，而现在真的找到了我们需要的虚拟地址，然后我们就可以解引用，将我们需要映射物理地址给他映射到这个三级页表中，也就是加入这个三级页表的表项！！！至此，我们的映射就完成了。

这里总结一下感受到的好处，像二级页表，三级页表实际上是通过kalloc分配的物理内存，所以会占用我们的内存，但是比起页偏移量| offset的形式，还是能够通过懒加载节省不少空间，并且寻址页变得更灵活，感觉分页还是很神奇的。

cpu咋根据虚拟地址找到你的物理地址？

对于CPU，我们的汇编中的所有代码涉及到的地址都仅仅是虚拟地址，而不是物理地址，然而，我们如何通过这样一个虚拟地址去找到我们的物理地址呢？在cpu中，有一个寄存器叫做satp，用来保存一个地址(实际上就是最高层级的地址，也就是进程的页表地址)，作为我们找到最终物理地址的参考，通过这个寄存器存储的地址，我们的cpu可以告诉MMU，从哪里可以找到将虚拟内存地址翻译成物理地址的"表单"，事实上，MMU就是充当了一个翻译器，它计算地址的功能实际上和walk函数是一样的，这样就能够实现准确的查找，而mmu属于硬件部分，不是我们分析的对象。

到了这里，我们的vm.c已经分析了一大半了。

在进行下一步之前，在这里记录一些概念：

TLB页表缓存

我们在之前涉及的函数中可以看到，我们的cpu是从最高级的页表进行查找对应的物理页，其中会涉及到三次跳转，索引都是存在物理页中的，所以需要读取三次内存，代价很高，所以实际上，我们的cpu都会对最近使用过的虚拟地址的翻译结果有缓存，这个缓存就好做页表缓存TLB，而TLB对于我们操作系统是不可见的，不是我们讨论的范畴，这里仅作了解，当然，如果cpu切换了我们的页表，我们过去缓存的的TLB当然也就不可用了，需要被清空，在riscv中，清空TLB的指令为：sfence_vma，我们可以在xv6中为数不多的几个汇编源文件中找到这个指令，比如trampoline.S。

插曲就到这里，下面我们涉足的地方将是关于内核的页表！

kvminit/kvminithart

事实上，内核的页表在启动的时候就会分配，我们可以在通过entry，一步一步找到我们的这两个函数的调用：

entry->start.c->main.c

首先，由于在启动xv6的时候，我们并没有映射物理地址，所以说会通过

  w_satp(0);

来禁用分页，在之后，我们就会通过物理地址直接返回到我们的main函数了。

我们可以在main.c中找到这样的代码：

    kvminit();       // create kernel page tablekvminithart();   // turn on paging

首先，就来看看我们的kvminit()

void
kvminit(void)
{kernel_pagetable = kvmmake();
}

可以看到，这里主要是调用了kvmmake函数来分配内核页表，进一步下去：

// 构建一个 kernel 的页表（direct-map 页表，虚拟地址 = 物理地址）。
// 内核代码、数据、外设、trampoline、内核栈都在此页表中映射。
pagetable_t
kvmmake(void)
{pagetable_t kpgtbl;// 通过kalloc分配页来作为内核的根页表kpgtbl = (pagetable_t) kalloc();memset(kpgtbl, 0, PGSIZE);  // 清零页表// 映射 UART 外设的寄存器地址（物理地址 = 虚拟地址）// 用于串口输出，例如 printf 打印信息kvmmap(kpgtbl, UART0, UART0, PGSIZE, PTE_R | PTE_W);// 映射 virtio 磁盘接口（内核需要访问硬盘控制器）kvmmap(kpgtbl, VIRTIO0, VIRTIO0, PGSIZE, PTE_R | PTE_W);
//以下不是我们目前需要关心的
//#ifdef LAB_NET
//
//  kvmmap(kpgtbl, 0x30000000L, 0x30000000L, 0x10000000, PTE_R | PTE_W);
//
//  kvmmap(kpgtbl, 0x40000000L, 0x40000000L, 0x20000, PTE_R | PTE_W);
#endif  // 映射 PLIC（中断控制器），允许内核收发中断kvmmap(kpgtbl, PLIC, PLIC, 0x4000000, PTE_R | PTE_W);// 映射内核代码段：可读、可执行（不可写，防止内核被修改）kvmmap(kpgtbl, KERNBASE, KERNBASE, (uint64)etext - KERNBASE, PTE_R | PTE_X);// 映射内核数据段：从 etext 到 PHYSTOP 的物理内存，可读写// 包括 bss 段、内核堆栈、内核堆等kvmmap(kpgtbl, (uint64)etext, (uint64)etext, PHYSTOP - (uint64)etext, PTE_R | PTE_W);// 映射 trampoline 页（trap 跳板）到最高虚拟地址处// trap handler 通过它进入内核；这是统一入口/出口kvmmap(kpgtbl, TRAMPOLINE, (uint64)trampoline, PGSIZE, PTE_R | PTE_X);// 为每个进程分配一个内核栈，并在页表中映射（stack for kernel mode）proc_mapstacks(kpgtbl);// 返回构造好的页表return kpgtbl;
}

可以看见，我们的kvmmake实际上就是新分配一个物理页表，随后进行一系列映射，将我们的页表都映射到内核的数据段，代码段所在的物理地址，使得我们可以进行访问。

我们可以进一步看看kvmmap是怎么做的：

void
kvmmap(pagetable_t kpgtbl, uint64 va, uint64 pa, uint64 sz, int perm)
{if(mappages(kpgtbl, va, sz, pa, perm) != 0)panic("kvmmap");
}

很明显，就是调用了我们之前说过的mappages，然后还会通过walk去找到三级页表，并且将物理页表的地址加到对应的表项中。

我们还看见了一个函数叫做proc_mapstacks,实际上就是为我们每个进程分配内核栈

void proc_mapstacks(pagetable_t kpgtbl)
{struct proc *p;// 遍历所有进程（proc 是进程表的数组，NPROC 是进程的最大数量）for(p = proc; p < &proc[NPROC]; p++) {// 分配一页物理内存给每个进程的内核栈char *pa = kalloc(); // kalloc 是一个内存分配函数，分配一页物理内存if(pa == 0)panic("kalloc"); // 如果分配失败，则触发 panic，表示内存不足// 计算该进程的内核栈的虚拟地址，KSTACK 是一个宏，通常用于计算栈的位置uint64 va = KSTACK((int) (p - proc)); // KSTACK 将进程的索引转化为虚拟地址// 将分配到的物理内存页映射到该进程的内核栈的虚拟地址kvmmap(kpgtbl, va, (uint64)pa, PGSIZE, PTE_R | PTE_W);// kvmmap 是将物理地址映射到虚拟地址的函数，PTE_R | PTE_W 表示该页具有读写权限}
}

这里在一开始，就为每个可能会被创建的进程分配了进程的内核栈，但是我看2020年的没有这样做。

随后，我们便可以回归到我们的kvminithart了！

void
kvminithart()
{// 清除所有旧的 TLB 项。// 以确保任何对页表的修改对 CPU 可见。// 这里的sfence_vma函数，实际上就是调用我们的riscv的sfence_vma命令！sfence_vma();// 将satp的值设置为我们刚刚分配的kernel页表w_satp(MAKE_SATP(kernel_pagetable));// 再次清除 TLB 中的条目，以防设置 satp 后仍存在旧的映射。sfence_vma();
}

到这里，我们实际上就是启用了我们的分页模式了。

简单总结一下，我们的xv6启动过程中，在分页上面干了什么事？

1. 链接的时候，start，main都是被识别为符号，此时还没有开启分页，编译器将他们识别为物理地址，而我们可以直接通过这些符号进行跳转，跳转到我们的main中。
2. 在我们的main中，会调用kvminit和kvminithart来初始化我们的内核页表。
3. kvminit先分配了一个主页表，随后将内核中的各种信息存放的物理地址映射到这个新建的页表中，并且提前为所有可能分配的进程创建内核栈。
4. kvminithart将启用我们的分页设置。

事实上，在我们修改satp的之后，我们的世界就改变了，但是在内核中，依旧可以正常工作，因为kernel page的映射关系中，虚拟地址到物理地址是完全相等的，这里比较特殊，我们的MMU依旧能够将其映射到相同的地址上，这里并不是特殊处理了，依旧只是通过 MMU 去找到的对应的地址，实际上，只是因为我们的内核页表映射的位置设计得很巧妙，如果你还是不理解怎么回事，你可以回去看看kvminit的映射地址时传入的参数。

---