文章目录
- 前言
- 一、Eliminate allocation from sbrk() (easy)
- 解析:
- 二、Lazy allocation (moderate)
- 解析:
- 三、Lazytests and Usertests (moderate)
- 解析:
- 总结
前言
一个本硕双非的小菜鸡,备战24年秋招。打算尝试6.S081,将它的Lab逐一实现,并记录期间心酸历程。
代码下载
官方网站:6.S081官方网站
安装方式:
通过 APT 安装 (Debian/Ubuntu)
确保你的 debian 版本运行的是 “bullseye” 或 “sid”(在 ubuntu 上,这可以通过运行 cat /etc/debian_version 来检查),然后运行:
sudo apt-get install git build-essential gdb-multiarch qemu-system-misc gcc-riscv64-linux-gnu binutils-riscv64-linux-gnu
(“buster”上的 QEMU 版本太旧了,所以你必须单独获取。
qemu-system-misc 修复
此时此刻,似乎软件包 qemu-system-misc 收到了一个更新,该更新破坏了它与我们内核的兼容性。如果运行 make qemu 并且脚本在 qemu-system-riscv64 -machine virt -bios none -kernel/kernel -m 128M -smp 3 -nographic -drive file=fs.img,if=none,format=raw,id=x0 -device virtio-blk-device,drive=x0,bus=virtio-mmio-bus.0 之后出现挂起
,
则需要卸载该软件包并安装旧版本:
$ sudo apt-get remove qemu-system-misc$ sudo apt-get install qemu-system-misc=1:4.2-3ubuntu6
在 Arch 上安装
sudo pacman -S riscv64-linux-gnu-binutils riscv64-linux-gnu-gcc riscv64-linux-gnu-gdb qemu-arch-extra
测试您的安装
若要测试安装,应能够检查以下内容:
$ riscv64-unknown-elf-gcc --version
riscv64-unknown-elf-gcc (GCC) 10.1.0
...$ qemu-system-riscv64 --version
QEMU emulator version 5.1.0
您还应该能够编译并运行 xv6: 要退出 qemu,请键入:Ctrl-a x。
# in the xv6 directory
$ make qemu
# ... lots of output ...
init: starting sh
$
一、Eliminate allocation from sbrk() (easy)
你的首项任务是删除sbrk(n)系统调用中的页面分配代码(位于sysproc.c中的函数sys_sbrk())。sbrk(n)系统调用将进程的内存大小增加n个字节,然后返回新分配区域的开始部分(即旧的大小)。新的sbrk(n)应该只将进程的大小(myproc()->sz)增加n,然后返回旧的大小。它不应该分配内存——因此您应该删除对growproc()的调用(但是您仍然需要增加进程的大小!)。
试着猜猜这个修改的结果是什么:将会破坏什么?
进行此修改,启动xv6,并在shell中键入echo hi。你应该看到这样的输出:
init: starting sh
$ echo hi
usertrap(): unexpected scause 0x000000000000000f pid=3sepc=0x0000000000001258 stval=0x0000000000004008
va=0x0000000000004000 pte=0x0000000000000000
panic: uvmunmap: not mapped
“usertrap(): …”这条消息来自trap.c中的用户陷阱处理程序;它捕获了一个不知道如何处理的异常。请确保您了解发生此页面错误的原因。“stval=0x0…04008”表示导致页面错误的虚拟地址是0x4008。
切换分支执行操作
git stash
git fetch
git checkout lazy
make clean
解析:
非常简单,删除sbrk(n)系统调用中的页面分配代码,并且新的sbrk(n)应该只将进程的大小(myproc()->sz)增加n,然后返回旧的大小。按照说得来就行。
uint64
sys_sbrk(void)
{int addr;int n;if(argint(0, &n) < 0)return -1;addr = myproc()->sz;/*if(growproc(n) < 0)return -1;*/myproc()->sz += n;return addr;
}
输出结果正常:
对照下面的图,显示是usertrap里面的缺页中断
二、Lazy allocation (moderate)
修改trap.c中的代码以响应来自用户空间的页面错误,方法是新分配一个物理页面并映射到发生错误的地址,然后返回到用户空间,让进程继续执行。您应该在生成“usertrap(): …”消息的printf调用之前添加代码。你可以修改任何其他xv6内核代码,以使echo hi正常工作。
提示:
- 你可以在usertrap()中查看r_scause()的返回值是否为13或15来判断该错误是否为页面错误
- stval寄存器中保存了造成页面错误的虚拟地址,你可以通过r_stval()读取
- 参考vm.c中的uvmalloc()中的代码,那是一个sbrk()通过growproc()调用的函数。你将需要对kalloc()和mappages()进行调用
- 使用PGROUNDDOWN(va)将出错的虚拟地址向下舍入到页面边界
- 当前uvmunmap()会导致系统panic崩溃;请修改程序保证正常运行
- 如果内核崩溃,请在kernel/kernel.asm中查看sepc
- 使用pgtbl lab的vmprint函数打印页表的内容
- 如果您看到错误“incomplete type proc”,请include“spinlock.h”然后是“proc.h”。
如果一切正常,你的lazy allocation应该使echo hi正常运行。您应该至少有一个页面错误(因为延迟分配),也许有两个。
解析:
首先按照提示,要修改usertrap()(kernel/trap.c)函数,查看r_scause()的返回值是否为13或15来判断该错误是否为页面错误。
根据提示,先查看uvmalloc()中的代码。
// Allocate PTEs and physical memory to grow process from oldsz to
// newsz, which need not be page aligned. Returns new size or 0 on error.
uint64
uvmalloc(pagetable_t pagetable, uint64 oldsz, uint64 newsz)
{char *mem;uint64 a;if(newsz < oldsz)return oldsz;//它将oldsz向上舍入到最近的页面边界。这是因为内存通常按页面大小进行分配oldsz = PGROUNDUP(oldsz);for(a = oldsz; a < newsz; a += PGSIZE){//使用kalloc函数分配一个页面大小的物理内存,并返回其地址mem = kalloc();if(mem == 0){uvmdealloc(pagetable, a, oldsz);return 0;}memset(mem, 0, PGSIZE);//使用mappages函数将物理内存页面映射到虚拟地址空间中if(mappages(pagetable, a, PGSIZE, (uint64)mem, PTE_W|PTE_X|PTE_R|PTE_U) != 0){kfree(mem);uvmdealloc(pagetable, a, oldsz);return 0;}}return newsz;
}
先判断发生错误的虚拟地址(r_stval()读取)是否位于栈空间之上,进程大小(虚拟地址从0开始,进程大小表征了进程的最高虚拟地址)之下,然后分配物理内存并添加映射
......
else if (r_scause() == 13 || r_scause() == 15) {uint64 virtual_address = r_stval();char *mem;if(PGROUNDUP(p->trapframe->sp) > virtual_address && virtual_address >= p->sz)return;mem = kalloc();virtual_address = PGROUNDDOWN(virtual_address);if(mem == 0){return;}memset(mem, 0, PGSIZE);if(mappages(p->pagetable, virtual_address, PGSIZE, (uint64)mem, PTE_W|PTE_X|PTE_R|PTE_U) != 0) {kfree(mem);p->killed = 1;}}
......
修改uvmunmap()(kernel/vm.c),之所以修改这部分代码是因为lazy allocation中首先并未实际分配内存,所以当解除映射关系的时候对于这部分内存要略过,而不是使系统崩溃,这部分在课程视频中已经解答。
......if((*pte & PTE_V) == 0)//panic("uvmunmap: not mapped");continue;
......
最后也是成功输出
三、Lazytests and Usertests (moderate)
我们为您提供了lazytests,这是一个xv6用户程序,它测试一些可能会给您的惰性内存分配器带来压力的特定情况。修改内核代码,使所有lazytests和usertests都通过。
- 处理sbrk()参数为负的情况。
- 如果某个进程在高于sbrk()分配的任何虚拟内存地址上出现页错误,则终止该进程。
- 在fork()中正确处理父到子内存拷贝。
- 处理这种情形:进程从sbrk()向系统调用(如read或write)传递有效地址,但尚未分配该地址的内存。
- 正确处理内存不足:如果在页面错误处理程序中执行kalloc()失败,则终止当前进程。
- 处理用户栈下面的无效页面上发生的错误。
如果内核通过lazytests和usertests,那么您的解决方案是可以接受的:
$ lazytests
lazytests starting
running test lazy alloc
test lazy alloc: OK
running test lazy unmap...
usertrap(): ...
test lazy unmap: OK
running test out of memory
usertrap(): ...
test out of memory: OK
ALL TESTS PASSED
$ usertests
...
ALL TESTS PASSED
$
解析:
处理sbrk()参数为负数的情况,参考之前sbrk()调用的growproc()程序,如果为负数,就调用uvmdealloc()函数,但需要限制缩减后的内存空间不能小于0
// Grow or shrink user memory by n bytes.
// Return 0 on success, -1 on failure.
int
growproc(int n)
{//定义了一个无符号整数 sz 来存储进程的当前大小uint sz;//并声明了一个指向 proc 结构体的指针 p用于获取当前进程的指针struct proc *p = myproc();//从 p 指向的 proc 结构体中获取当前进程的大小,并将其存储在 sz 中sz = p->sz;//如果 n 大于 0,则尝试增加内存。使用 uvmalloc 函数来增加从 sz 到 sz + n 的内存。如果 uvmalloc 返回 0,表示内存分配失败,函数返回 -1if(n > 0){if((sz = uvmalloc(p->pagetable, sz, sz + n)) == 0) {return -1;}} else if(n < 0){//如果 n 小于 0,则尝试减少内存。使用 uvmdealloc 函数来释放从 sz 到 sz + n 的内存。注意这里即使 uvmdealloc 可能失败(尽管函数签名没有显示返回值或错误处理),该函数也不会检查返回值或返回错误sz = uvmdealloc(p->pagetable, sz, sz + n);}p->sz = sz;return 0;
}
修改之后的sys_sbrk:
uint64
sys_sbrk(void)
{int addr;int n;if(argint(0, &n) < 0)return -1;addr = myproc()->sz;uint sz;struct proc *p = myproc();sz = p->sz;if(n > 0){p->sz += n;} else if(sz + (n > 0){sz = uvmdealloc(p->pagetable, sz, sz + n);p->sz = sz;} else {return -1;}return addr;
}
正确处理fork的内存拷贝:fork调用了uvmcopy进行内存拷贝,现在让其直接进入下一页,而不是报错,所以修改uvmcopy如下
if((pte = walk(old, i, 0)) == 0)//panic("uvmcopy: pte should exist");continue;if((*pte & PTE_V) == 0)//panic("uvmcopy: page not present");continue;
还需要继续修改uvmunmap,同样的问题,同样的方式
if((pte = walk(pagetable, a, 0)) == 0)//panic("uvmunmap: walk");continue;if((*pte & PTE_V) == 0)//panic("uvmunmap: not mapped");continue;
以上部分搞完之后我就去测试了,然后就g了。。。
看了大佬们的讲解,应该是write错了。
因为我们现在采用的是懒分配,写的时候由于此时传入的地址还未实际分配(因为还没映射,只分配了虚拟地址),就不能走到上文usertrap中判断scause是13或15后进行内存分配的代码。
解决办法我看到了两种:
一种是在walkaddr寻找物理地址时,如果发现虚拟地址没有映射,就给它实际分配一下。
另外一种是系统通过argaddr函数从寄存器中读取地址时添加物理内存分配的代码。
都可以解决,也没啥区别。
我采用在walkaddr函数中更改。代码总体跟之前的uvmalloc没差太多,毕竟是一个功能的。
uint64
sys_sigalarm(void) {struct proc *p;p = myproc();argint(0, &p->alarm_interval);argaddr(1, &p->handler);p->ticks_count = 0;return 0;
}uint64
sys_sigreturn(void) {return 0;
}
最后在trap.c中的usertrap()中处理.
增加用户报警函数的地址可能是0的判断。当进程的报警间隔期满时(也就是两次报警间的滴答计数达到了报警间隔),用户进程执行处理程序函数。
// give up the CPU if this is a timer interrupt.if(which_dev == 2) {if (p->alarm_interval != 0) {p->ticks_count++;if (p->ticks_count == p->alarm_interval) {p->ticks_count = 0;p->trapframe->epc = p->handler;}}}yield();
没有什么问题
题目二中要解决的主要问题是寄存器保存恢复和防止重复执行的问题。
要在usertrap中再次保存用户寄存器,当handler调用sigreturn时将其恢复,并且要防止在handler执行过程中重复调用。
再在struct proc中新增两个字段
int is_alarming; // 是否正在执行告警处理函数
struct trapframe* alarm_trapframe; // 告警陷阱帧
同时记得在allocproc中将它们初始化为0,并在freeproc中也设为0
// 增加不是修改// 进程初始化,这里主要是防止申请不成功,那就学着已有的代码对进程进行销毁if((p->alarm_trapframe = (struct trapframe *)kalloc()) == 0){freeproc(p);release(&p->lock);return 0;}p->pid = allocpid();p->ticks_count = 0;p->alarm_interval = 0;p->handler = 0;p->is_alarming = 0;//增加不是修改if(p->alarm_trapframe)kfree((void*)p->alarm_trapframe);p->trapframe = 0;p->is_alarming = 0;
更改usertrap函数,保存进程陷阱帧p->trapframe到p->alarm_trapframe
// give up the CPU if this is a timer interrupt.if(which_dev == 2) {if (p->alarm_interval != 0) {p->ticks_count++;if (p->ticks_count >= p->alarm_interval && p->is_alarming == 0) {memmove(p->alarm_trapframe, p->trapframe, sizeof(struct trapframe));p->is_alarming == 1;p->ticks_count = 0;p->trapframe->epc = (uint64)p->handler;}}}yield();usertrapret();
}
最后修改sys_sigreturn函数,恢复陷阱帧。
uint64
sys_sigreturn(void) {struct proc *p;p = myproc();memmove(p->trapframe, p->alarm_trapframe, sizeof(struct trapframe));p->is_alarming = 0;return 0;
}
总结
这个实验成功的带着我们实现了回溯,中断的处理过程并如何恢复初始状态。从系统调用中梳理中断的全流程。收获颇丰。