WeensyOS Minilab 2

Due Monday, November 13 at 11:59pm

This minilab is a tiny operating system that will demonstrate the concepts behind virtual memory.

weensyos2.tar.gz Source code for WeensyOS 2.0, the Memory OS

Handing in

You will electronically hand in code and a small writeup. The problem set code, weensyos2.tar.gz, unpacks into a directory called weensyos2. You'll modify the code in this directory, and add a text file with your answers to the numbered questions. When you're done, run the command gmake tarball. This should create a file named weensyos2-yourusername.tar.gz, which you will submit to CourseWeb.

Answers to the numbered questions should be in a file named answers.txt, answers.html, or answers.pdf. Text files are strongly preferred.

To review:

Download and unpack weensyos2.tar.gz.
Do your work in the weensyos2 directory.
Put your answers to the numbered questions in a answers.txt file (or answers.html or answers.pdf) in that weensyos2 directory.
When you're done, run gmake tarball from the weensyos2 directory. This will create a file named weensyos2-yourusername.tar.gz.
Submit that weensyos2-yourusername.tar.gz file to CourseWeb.

Physical Memory

Download and unpack the source for weensyos2, then boot your emulated computer running MemOS with the gmake run-memos command.

% gzcat weensyos2.tar.gz | tar xf -
% ls weensyos2
COPYRIGHT    elf.h       memos-2.ld   memos-boot.c    memos-x86.c   x86mem.h
GNUmakefile  lib.c       memos-3.c    memos-kern.c    memos.h       x86struct.h
answers.txt  lib.h       memos-3.ld   memos-kern.h    mergedep.pl   x86sync.h
bootstart.S  memos-1.c   memos-4.c    memos-loader.c  mkbootdisk.c
conf         memos-1.ld  memos-4.ld   memos-pages.c   types.h
console.c    memos-2.c   memos-app.h  memos-trap.S    x86.h
% gmake run-memos
+ hostcc mkbootdisk.c
+ as bootstart.S
+ cc memos-boot.c
...
+ mk memos.img
+ bochs memos.img
========================================================================
                       Bochs x86 Emulator 2.2.1
                Build from CVS snapshot on July 8, 2005
========================================================================
00000000000i[     ] reading configuration from .bochsrc
Next at t=0
(0) [0xfffffff0] f000:fff0 (unk. ctxt): jmp far f000:e05b         ; ea5be000f0
<bochs:1>

The Bochs emulator stops in case you want to enter a breakpoint. You shouldn't need any breakpoints for this lab, so at the <bochs:1> prompt, just enter c to continue. In your Bochs window, you should see something like this:

(This image loops forever, but when you run MemOS, the bars will move to the right and stay there.)

If your bochs runs too slowly (the bars of 1-4's move slowly), edit the memos.h file and reduce the ALLOC_SPEED constant.

Here's what's going on.

MemOS displays the current state of physical memory. Each character represents 4 KB of memory: a single physical page. There is 2 MB of physical memory in total.
The MemOS runs four processes, 1 through 4.
Since the MemOS initially uses physical memory allocation, each process must use a separate region of memory. We preallocate 1/4 MB for each process.
Each process asks the kernel for more heap space, one page at a time, until it runs out of room. As usual, each process's heap begins just above its code and global data, and ends just below its stack. The processes allocate space at different rates: compared to Process 1, Process 2 allocates space twice as fast, Process 3 goes three times as fast, and Process 4 goes four times as fast. (A random number generator is used, so the exact rates may vary.)

The marching rows of 1's, 2's, 3's, and 4's show how fast the heap spaces for processes 1, 2, 3, and 4 are allocated. Here are two labeled memory diagrams, showing what the characters mean and how memory is arranged.

Read and understand the process code in memos-1.c. This code is used for all 4 processes.

Virtual Memory: One Address Space

In the rest of this lab, you will gradually switch the MemOS to use virtual memory! This requires that we set up different address spaces, one for each process, and change the page allocation function, page_alloc, to allocate a physical page and map it at the required address, rather than simply allocating the physical page with the right address. First, we'll simply set up a single virtual address space that matches physical memory.

Exercise A: Implement the page_get_free function in memos-pages.c. This function should use the page_state array to find a page that is currently free.

Exercise B: Edit the start function in memos-kern.c to initialize virtual memory. After the call to page_state_init(), add the following two lines:

        initial_pgdir = pgdir_new();
        paged_virtual_memory_init(initial_pgdir);

The pgdir_new() function creates and returns an initial address space (page directory) with mappings for all of physical memory. The paged_virtual_memory_init function turns on paged virtual memory. Its argument is installed as the initial page directory.

Read and understand the page_alloc function in memos-pages.c.

Exercise C: Edit the page_alloc function to add a user-accessible page mapping for the physical page it allocates. You'll need to call the page_map_user function.

If you run gmake run-memos at this point, it should work, and produce similar output as it did before. But let's take a look at each process's virtual address space as well.

Exercise D: In the trap function in memos-kern.c, after the call to show_physical_memory(), add the following line:

        show_virtual_memory_flipper();

When you run gmake run-memos now (and enter c at the <bochs:1> prompt), you should see something like this.

There are several changes from the initial display.

As the MemOS runs, the virtual memory display cycles between the four processes' address spaces. However, all the address spaces are the same for now. (If Bochs cycles through the address spaces too slowly, reduce the MEMORY_FLIPPER_SPEED constant in memos.h.)
The new "P" character indicates a memory page used for a page directory or page table: that is, for a structure used to represent an address space. Intel 386-compatible processors use a hardware-defined two-level page table format, so each address space requires at least two pages of memory.
Blank spaces in the virtual memory display represent unmapped addresses. If a process tries to access such an address, it will page fault.
In the virtual memory display, a character is reverse-video if a user-mode process is allowed to access the corresponding address. Thus, we can see that the processes can't modify the kernel's code, data, or stack, or the I/O memory (except for the single page that contains the console). However, each process can modify any other process's code, data, or heap.

Virtual Memory: Isolated Address Spaces

MemOS is now using virtual memory, but we're getting no benefit from it! Next, we'll update the kernel code to grant each process its own address space. This will isolate the processes from one another; no process will be able to alter another process's memory or data.

There are three changes required.

MemOS must create a new address space (page directory) for each process. It creates that address space during process descriptor initialization. Since the kernel portion of all processes' address spaces will be identical, the kernel may freely switch between those address spaces without causing page faults on kernel code or data.
The kernel must switch to a process's address space before loading that process's code and data into memory with process_load().
The kernel must switch to a process's address space before running that process's code.

Switching to an address space uses the lcr3() function, a simple wrapper for the lcr3 instruction. The 386+'s cr3 register holds the physical address of the active page directory; kernel code may change the value of this register, and thus switch to a new address space, by calling lcr3() with the relevant page directory address.

Exercise E: Change the process initialization code in start() to give each process its own independent address space. Use the lcr3() function to switch to each process's address space before calling process_load(). Note that the pgdir_new() function creates a new, independent address space and returns the physical address of a page directory.

Exercise F: Change the run() function in memos-kern.c to load the process's address space before running that process.

Now when you run gmake run-memos, you should see something like this. (Note the greater number of "P" pages.)

Now each process's address space only contains that process's pages. Furthermore, since processes run in user mode (at protection level 3), the processor will not allow them to execute the lcr3 and lcr0 instructions that would install a new address space or turn off virtual memory. This means the processes are memory isolated: no process can affect another process's code or data.

Question 1: Memory isolation also depends on properties of the processes' page tables. Which types of page must be marked as inaccessible or kernel-only to guarantee memory isolation? List only those pages that must be inaccessible so that no process can observably affect another process's behavior via reading or writing memory. (The console doesn't count.)

Virtual Memory: Address Mapping

MemOS now maintains an isolated address space for each process. However, it still allocates memory based on physical address. Given virtual memory, we can allocate memory far more flexibly. In this section, you will change MemOS to allocate memory independently of physical address, and to give each process a much larger heap space, allowing any process to potentially allocate most available physical memory.

Exercise G: Edit the page_alloc function so that it can use any free page, rather than just the physical page with the given address. If no free page is available, page_alloc should return -1. Your kernel should continue to work even after physical memory is exhausted.

Exercise H: Initialize each process's stack to start at virtual address 0x300000, the top of MemOS's virtual address space.

Now when you run gmake run-memos, you should see something like this.

[MemOS Virtual Address Spaces with Address Mapping]

You have now built a virtual memory system that, in its essentials, is a lot like the virtual memory system in any modern operating system.

Notice that once physical memory is exhausted, Process 4 has used roughly four times as much memory as Process 1. This is because each process's address space is big enough to fit any available physical memory, so physical memory runs out before any process's address space does. Now that we have eliminated the requirement that processes fit in contiguous regions of physical memory, each process can allocate more memory than before!

Question 2: Process 1's code and global data used to be allocated in physical page numbers 0x100 and 0x101 (physical addresses 0x100000 and 0x101000). In your implementation, which physical page numbers are now used for Process 1's code and global data (i.e., not including its heap or stack)?

Question 3: Why haven't the physical page numbers allocated for kernel code and data changed? Refer to the state of the machine's MMU at boot time (while the boot loader, which loads the kernel from disk, is running).

Extra Credit Exercise: It's not necessarily fair that Process 4 gets to use four times as much memory as Process 1 -- especially since Process 1 can get less memory than in the original physically-allocated design. Implement a quota system so that each process is guaranteed that it will be able to allocate at least 1/4 MB (64 pages) of heap space (not including any code, data, and stack space). Any space beyond that 1/4 MB should be allocated first-come, first-served. You will need to keep track of how much physical memory remains available, and how much physical memory each process has allocated. Add some text to answers.txt to describe your implementation.

This completes the minilab. Make sure you have answered all three numbered questions in your answers.txt file.