M3: A pager

Use your memory manager from M2 to write a simple pager.

Current Implementation

The current implementation simply pre-maps in the pages for the single binary that our initial code supports. Any actual VM faults simply trigger an assert() which halts the system. The executable itself is mapped in with untracked frames (i.e. we leak them), and finally, the current sos application malloc implementation uses a static array - it must be changed to use virtual memory (see libs/libsos/src/sys_morecore.c).Note: There are two versions of morecore() in the system. The version mentioned above which malloc uses in sos applications, and another version that sos itself uses internally. Be careful you are modifying the morecore for sos applications.

The Milestone

• Implement a page table to translate virtual memory addresses to frame table entries. You need to consider where you will keep track of cptrs to both levels of the page table and to the frames themselves. Note: ARM uses a 16K level-one page directory and a 1K level-two page table, i.e. 12-bits index the top level, and 8-bits index the second level. You do not have to follow this split, but you do need to theoretically keep track of the cptrs to the potential page tables. So if SOS applications have a 2GB address space, you potentially need to keep track of 2^11 cptrs.
• Using our code as a guide only, create your own version of the map_page(). Your version (say sos_map_page()) will need to populate and use your data structures to keep track of address spaces, virtual addresses, frame physical addresses and cptrs. Note: The existing map_page() is used internally and thus needs to continue to work as before, so be careful if modifying it.
• Design your user level address space layout and permissions - including the stack, heap and other sections. You may wish to consider a region-like abstraction like OS/161.
• Change the current user malloc implementation to use virtual memory, not a static array (just allow it to fault in memory by increasing its upper bound)
• Modify the bootstrap ELF-loading code to use your modified pager mapping functions, not the frame table directly.

Design alternatives

Probably the main thing that you should consider here is the layout of your processes address space. Some things you will want to consider is where you place various parts of memory such as the stack, heap and code segments. You may also have some other regions in your process address space, one of these is the IPC Buffer.

You should also think about if you want to make different ranges of the address space have different permissions, eg: you may want to make code read-only to prevent bugs, or have a guard page at the end of your stack to prevent overflow.

Assessment

The main demonstration here will be to show a user process running with a high stack pointer (> 0x2000000). You should also demonstrate a user process using malloc() from a heap.

#define NPAGES 128

/* called from pt_test */
static void
do_pt_test( char *buf )
{
    int i;

    /* set */
    for(i = 0; i < NPAGES; i += 4)
	buf[i * 1024] = i;

    /* check */
    for(i = 0; i < NPAGES; i += 4)
	assert(buf[i*1024] == i);
}

static void
pt_test( void )
{
    /* need a decent sized stack */
    char buf1[NPAGES * 1024], *buf2 = NULL;

    /* check the stack is above phys mem */
    assert((void *) buf1 > (void *) 0x2000000);

    /* stack test */
    do_pt_test(buf1);

    /* heap test */
    buf2 = malloc(NPAGES * 1024);
    assert(buf2);
    do_pt_test(buf2);
    free(buf2);
}

You should also be able to explain to the tutor how your code works and any design decisions you took.