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.
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.more ...
We'll talk about
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
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.more ...
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
Here are some practice that will hopefully make you feel more comfortable and more productive when you poking around with os161 syscalls.more ...
Let's use the
fork system call as an example. For convinience, let's assume
$OS161_SRC is your os161 source root directory.