mmap

1. mmap需要将文件映射到某处虚拟内存中，我们需要使用vm提供的接口 mmappages 映射虚拟内存与物理地址，fs提供的接口 readi 读取fd对应的文件
2. 如果用户不指定映射地址（本实验指定情形），则需从虚拟地址空间中中找一个足够大的连续地址进行映射
3. 另外，需要使用 page fault 机制对文件进行copy on read&write 读取，我们需要支持比实际物理内存大得多的文件
4. 为了保证识别出由mmap引起的page fault，需要添加标志位 PTE_MMAP
5. 为了在page fault机制中恢复页的标志位、跟踪mmap文件的状态，需要为进程添加结构体 vma，它包含了内存映射文件剩余的大小、下一个vma的指针、起始的虚拟地址、权限、是否shared等等
6. 在munmap中，根据文件的共享状态选择是否将脏页写入磁盘，取消pte映射并释放物理页，更新vma。在vma大小为0时，释放这个vma，它可以被其他内存映射文件复用
7. fork和exit时，同样需要复制和释放vma
8. 以及其他海量的细节，需要修改部分xv6的源码

遇到的一些bug

补齐数据

大于文件大小但小于一页的部分需要用0补齐

只读方式打开的文件可以以 private writable 的方式进行内存映射，而shared不行

丢失物理页

奇怪的bug：明明还有很多物理页，此时却显示没有了：

由于kalloc的逻辑是：

它会把下一个物理页的地址直接放在本页的首部区域，这个数据可能被某个跨界的读写操作修改了，且至少修改了8个字节的数据。比如这段代码：

修改后就ok了：

mmap的部分页表未复制

只复制了5页，而原页表有9页。所以mmap时应该需要增加p->sz，munmap时需要减去一定的大小

mmap 破碎的页表

mmap映射的文件可能是支零破碎的，因为你可能还有很多munnap，这导致了如今的uvmunmap的逻辑不适用——它假定从va开始一段内存都有效，都是连续的。

需要单独映射mmap页到一个位置，由于实验保证不会在中间打洞，所以可以保持uvmunmap的逻辑不变。于是原先的mmap和munmap改变sz可以作废，另外需在exit中单取消映射这一段内存