DOC PREVIEW
UMD CMSC 412 - Project 4: Virtual Memory

This preview shows page 1 out of 4 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 4 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 4 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Chapter 9Project 4: Virtual Memory9.1 IntroductionThe purpose of this project is to add paging to the GeekOS kernel. This will require many small, but difficultchanges to your project. More than any previous project, it will be important to implement one thing, test itand then move to the next one.9.2 Changing the Project to Use Page TablesThe first step is to modify your project to use page tables and segmentation rather than just segments toprovide memory protection. To enable using page tables, every region of memory your access (both kerneland data segment) must have an entry in a page table. The way this will work is that there will be a singlepage table for all kernel only threads, and a page table for each user process. In addition, the page tables foruser mode processes will also contain entries to address the kernel mode memory. The memory layout forthis is shown inFigure 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 (thislimits the physical memory of the processor to 2GB, but this is not a critical limit for this project). The pagetable entries for this memory should be marked so that this memory is only accessible from kernel mode339.3. HANDLING PAGE FAULTS CHAPTER 9. PROJECT 4: VIRTUAL MEMORY(i.e. the userMode bit in the page directory and page table should be 0). To make this change, you shouldstart by creating a page directory and page table entries for the kernel threads by writing a function thatinitializes 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 allocatepage tables for the entire region that will be mapped into this memory context. You will need to fill out theappropriate fields in the page tables and page directories, which are represented by the pte t and pde tdatatypes defined in <geekos/paging.h>. Finally, to enable paging for the first time, you will need tocall an assembly routine, Enable Paging(), that will take the base address of your page directory as aparameter and then load the passed page directory address into register cr3, and then set the paging bit incr0 (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 stepprocess. First, you need to allocate a page directory for this user space. You should copy all of the mappingsfrom the kernel mode page directory for those memory regions in the low range of memory. Next you needto allocate page table entries for the user processes text and data regions. Do not allocate extra space for thestack here. Finally, you should allocate space for one page of stack memory at the end of the virtual addressrange (i.e. the last entry in the last page table). For the user space page mappings, make sure to enable theuserMode 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 shouldchange the code and data segments for user processes so that the base address is be 0x80000000, and thelimit is 0x80000000. This will allow the user space process to think that its virtual location 0 is the 2GBpoint in the page layout and will greatly simplify your kernel compared to traditional paged systems. Youwill also need to add code to Switch To Address Space() to switch the PTBR register (cr3) as part ofa context switch; where you load the LDT of the user context, you should also load the address of the pagedirectory for the process, which is the pageDir field in the User Context structure.1When you are allocating pages of memory to use as part of a user address space, you should use a newfunction, Alloc Pageable Page() (prototype in <geekos/mem.h>. The primary difference is that anypage allocated by this routine should have a special flag PAGE PAGEABLE set in the flags field of its entryin the corresponding Page data structure. Having this flag set marks the page as being eligible to be stolenand paged out to disk by the kernel when a page of memory is needed elsewhere, but no free pages areavailable. Note that you should not allocate page tables or page directories using this function.9.3 Handling Page FaultsOne of the key features of using paging is to have the operating system handle page faults. To do this youwill need to write a page fault interrupt handler. The first thing the page fault handler will need to do isto determine the address of the page fault; you can find out this address by calling the Get Page FaultAddress() function (prototype in <geekos/paging.h>. Also, the errorCode field of the InterruptState data structure passed to the page fault interrupt handler contains information about the faultingaccess. This information is defined in the faultcode t data type defined in <geekos/paging.h>. Oncethe fault address and fault code have been obtained, the page fault handler will need to determine anappropriate action to take. Possible reasons for a page fault, and the action to take are shown in Figure 9.2.9.4 Paging Out PagesAt some point, your operating system will run out of page frames to assign to processes. In this case, youwill need to pick a page to evict from memory and write it to the backing store (paging file). You should1You may choose to allocate the user code and data segment descriptors in the GDT (Global Descriptor Table) rather than having aseparate LDT for each process. If you decide to use this approach, then the User Context will not need to contain an LDT or selectorfields. 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 eachnewly created process. Each user process can use the same user code and data segments; because each process uses a separate virtualaddress space, there is no way that a process can access another process’s memory.34CHAPTER 9. PROJECT 4: VIRTUAL MEMORY 9.5. PAGE INSFigure 9.2: Actions to be taken when a page fault occurs.implement a version of pseudo-LRU. Use the reference bit in the page tables to keep track of how frequentlypages are accessed. To do this, add a clock field to the Page structure in <geekos/mem.h>. You shouldupdate the clock on every page


View Full Document

UMD CMSC 412 - Project 4: Virtual Memory

Documents in this Course
Security

Security

65 pages

Deadlocks

Deadlocks

22 pages

Set 2

Set 2

70 pages

Project 2

Project 2

21 pages

Load more
Download Project 4: Virtual Memory
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Project 4: Virtual Memory and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Project 4: Virtual Memory 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?