Sys161 will panic if you try to write a TLB entry with a entryhi, but there are already a TLB entry with the same entryhi but in a different TLB slot. This is because entryhi should be a UNIQUE key in the TLB bank.

Now that you can allocate/free physical pages, and you have demand paging through handling TLB miss. Let's get the final part work: swapping.

Now we've set up user address space, it's time to handle TLB/page faults. Note that there is a difference between TLB and page faults:

• TLB fault means the hardware don't know how to translate a virtual address since the translation didn't present in any TLB entry. So the hardware raise a TLB fault to let the kernel decide how to translate that address.

• Page fault means the user program tries to access a page that is not in memory, either not yet allocated or swapped out.

If you're not familiar with sbrk system call, here is it's wiki, and its interface description. In a nutshell, malloc will use sbrk to get heap space.

Now we've set up our coremap and also have the routines to allocate and free physical pages. It's the time to set up user's virtual address space.

Basically, we'll adopt two-level page table. If you're not already familiar with this, you can check out the page table wiki and this document talking about MIPS and X86 paging.

We'll talk about page_alloc, page_free, alloc_kpages and free_kpages.

The first concern of OS161 virtual memory system is how to manage physical pages. Generally, we can pack a physical page's information into a structure (called struct coremap_entry) and use this struct to represent a physical page. We use an array of struct coremap_entry to keep all physical pages information. This array, aka, coremap, will be one of the most important data structure in this lab.

Here are various documents that I found helpful for implementing OS161 virtual memory system.