最后的问题：
- We have placed the kernel and user environment in the same address space. Why will user programs not be able to read or write the kernel’s memory? What specific mechanisms protect the kernel memory?
页表本身的保护机制，在调用boot_map_region的时候，最后一个参数我们传入的是PTE_W,只容许特权级为0(内核)来读这个页表项指向的物理页框。 - 此操作系统可以支持的最大物理内存量是多少？为什么？
在page2pa函数的实现中可以看到
static inline physaddr_t
page2pa(struct PageInfo *pp) {
return (pp - pages) << PGSHIFT;
}
pp的值都是大于pages的，也就是以pages这个虚拟地址为基址，pp-pages就是偏移量，每一个单位的偏移量是一个指针的大小4Byte。在pages的(虚拟)地址到UVPT(虚拟)地址的这一块位置就是用来放置struct PageInfo结构体的，PADDR(pp)就有点不太懂。
* ULIM, MMIOBASE --> +------------------------------+ 0xef800000
* | Cur. Page Table (User R-) | R-/R- PTSIZE
* UVPT ----> +------------------------------+ 0xef400000
* | RO PAGES | R-/R- PTSIZE
* UPAGES ----> +------------------------------+ 0xef000000
这里UPAGES对应的就是pages这个链表。程序空间在利用虚拟地址访问pages的时候。一旦大于4MB，比如越界到了UVPT这个空间。由于这部分虚拟地址是放到了kern_pgdir里面。所以这个时候超出的部分就不能访问了。也就意味着：物理空间上，pages占用多大空间都没有问题。但是虚拟地址空间在访问UPAGES的时候就是不能访问全。一个struct PageInfo的大小是8byte，4MB/8Byte = 0.5M个页面，每个页面4KB，所有0.5M*4KB=2GB大小。所以物理内存最大是2GB大小。
- How much space overhead is there for managing memory, if we actually had the maximum amount of physical memory? How is this overhead broken down?
PageInfo结构体占据了4MB，页表项是0.5M个(1024的倍数，为什么是1024？因为每个页表有1024个页表项目)，所以所有页表项总和大小是0.5M*4Byte= 2MB，又因为页目录项本身有大小(4KB),所以结算起来一共6MB+4KB。
