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.

One principle of kernel programming is that: do not trust anything users passed in. Since we assume that users are bad, they will do anything they can to crash the kernel (just as $OS161_SRC/user/testbin/badcall/badcall.c do). So we need pay special attention to the arguments of the system calls, especially the pointers.

Here are some practice that will hopefully make you feel more comfortable and more productive when you poking around with os161 syscalls.

Let's use the fork system call as an example. For convinience, let's assume $OS161_SRC is your os161 source root directory.