


Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Material Type: Project; Class: Operating Systems; Subject: Computer Science; University: University of Maryland; Term: Unknown 1989;
Typology: Study Guides, Projects, Research
1 / 4
This page cannot be seen from the preview
Don't miss anything!



The purpose of this project is to add paging to the GeekOS kernel. This will require many small, but difficult changes to your project. More than any previous project, it will be important to implement one thing, test it and then move to the next one.
The first step is to modify your project to use page tables and segmentation rather than just segments to provide memory protection. To enable using page tables, every region of memory your access (both kernel and data segment) must have an entry in a page table. The way this will work is that there will be a single page table for all kernel only threads, and a page table for each user process. In addition, the page tables for user mode processes will also contain entries to address the kernel mode memory. The memory layout for this is shown in Figure 9.1.
Figure 9.1: Virtual memory layout in GeekOS.
The kernel memory should be a one to one mapping of all of the physical memory in the processor (this limits the physical memory of the processor to 2GB, but this is not a critical limit for this project). The page table entries for this memory should be marked so that this memory is only accessible from kernel mode
(i.e. the userMode bit in the page directory and page table should be 0). To make this change, you should start by creating a page directory and page table entries for the kernel threads by writing a function that initializes the page tables and enables paging mode in the processor. You will do this in the Init VM() function in src/geekos/paging.c. To set up page tables, you will need to allocate a page directory (using Alloc Page()) and then allocate page tables for the entire region that will be mapped into this memory context. You will need to fill out the appropriate fields in the page tables and page directories, which are represented by the pte t and pde t datatypes defined in <geekos/paging.h>. Finally, to enable paging for the first time, you will need to call an assembly routine, Enable Paging(), that will take the base address of your page directory as a parameter and then load the passed page directory address into register cr3, and then set the paging bit in cr0 (the MSB, bit 31). The next step is to modify your user processes to all use pages in the user region. This is a two step process. First, you need to allocate a page directory for this user space. You should copy all of the mappings from the kernel mode page directory for those memory regions in the low range of memory. Next you need to allocate page table entries for the user processes text and data regions. Do not allocate extra space for the stack here. Finally, you should allocate space for one page of stack memory at the end of the virtual address range (i.e. the last entry in the last page table). For the user space page mappings, make sure to enable the userMode bits in both the page directory and page table entries. You will also need to change some aspects of how the code from Project 1 sets things up. You should change the code and data segments for user processes so that the base address is be 0x80000000, and the limit is 0x80000000. This will allow the user space process to think that its virtual location 0 is the 2GB point in the page layout and will greatly simplify your kernel compared to traditional paged systems. You will also need to add code to Switch To Address Space() to switch the PTBR register (cr3) as part of a context switch; where you load the LDT of the user context, you should also load the address of the page directory for the process, which is the pageDir field in the User Context structure. 1 When you are allocating pages of memory to use as part of a user address space, you should use a new function, Alloc Pageable Page() (prototype in <geekos/mem.h>. The primary difference is that any page allocated by this routine should have a special flag PAGE PAGEABLE set in the flags field of its entry in the corresponding Page data structure. Having this flag set marks the page as being eligible to be stolen and paged out to disk by the kernel when a page of memory is needed elsewhere, but no free pages are available. Note that you should not allocate page tables or page directories using this function.
One of the key features of using paging is to have the operating system handle page faults. To do this you will need to write a page fault interrupt handler. The first thing the page fault handler will need to do is to determine the address of the page fault; you can find out this address by calling the Get Page Fault Address() function (prototype in <geekos/paging.h>. Also, the errorCode field of the Interrupt State data structure passed to the page fault interrupt handler contains information about the faulting access. This information is defined in the faultcode t data type defined in <geekos/paging.h>. Once the fault address and fault code have been obtained, the page fault handler will need to determine an appropriate action to take. Possible reasons for a page fault, and the action to take are shown in Figure 9.2.
At some point, your operating system will run out of page frames to assign to processes. In this case, you will need to pick a page to evict from memory and write it to the backing store (paging file). You should
(^1) You may choose to allocate the user code and data segment descriptors in the GDT (Global Descriptor Table) rather than having a separate LDT for each process. If you decide to use this approach, then the User Context will not need to contain an LDT or selector fields. Instead, you should define user mode code and data segments in the GDT using the Allocate Segment Descriptor() function, before any user process is created, and create selectors for these segments to use for the code and data segment registers for each newly created process. Each user process can use the same user code and data segments; because each process uses a separate virtual address space, there is no way that a process can access another process’s memory.
In order to implementing virtual memory and paging, you will need to implement several functions.
The implementation of virtual memory in GeekOS is a very simple one. There are many ways that it can be extended and improved.
When a page of pageable memory is required and no pages are available, the kernel uses the Find Page To Page Out() function (in src/geekos/mem.c) to select a page to page out. While interrupts are disabled (meaning no other threads or interrupt handlers can run), this function traverses the array of all Page data structures, in order to find the one with the oldest clock field. How can you make this function work more efficiently?