you will design and implement a pager, part of the kernel that manages application processes\' virtual address spaces

INSTRUCTIONS TO CANDIDATES

ANSWER ALL QUESTIONS

1. Overview

In this project, you will design and implement a pager, part of the kernel that manages application processes' virtual address spaces. Your pager will manage a portion of each application process's address space; we call this portion the arena. Pages in the arena will be stored in physical memory, in a swap file, or in a regular file. Your pager will manage these resources on behalf of all the applications it manages.

Your pager will implement system calls that applications can use to create, copy, and destroy address spaces, allocate space in an existing address space, and switch between address spaces. Your pager will also implement the interrupt handler for memory faults.

This handout is organized as follows:

Section 2 describes the overall structure of the system.

Section 3 describes the simulated hardware used in this project.

Section 4 describes the system calls that applications can use to communicate explicitly with the pager.

Sections 5 and 6 are the main sections; they describe the functionality that you will implement in the pager and how to design your pager to minimize work.

Section 7 describes how your pager will maintain the emulated page tables and access physical memory and files.

Section 8 gives some hints for doing the project,

Sections 9-12 describe the test suite and project logistics/grading.

2. System structure

The system has two types of entities: application processes and the kernel (you are writing the pager part of the kernel). Application processes communicate with the kernel via system calls and page faults. In turn, the kernel provides processes with the address space abstraction by reading and writing physical memory, files, swap space, page tables, and the page table base register.

 (The kernel also has an address space, but you are not responsible for managing the kernel's address space).

Applications interact with the kernel through the following mechanisms (summarized by the diagram below):

An application requests service from the kernel by making system calls. This project deals with the following system calls: fork , exit , vm_yield , and vm_map . A system call invokes the computer's exception handling mechanism, which transfers control safely to the registered kernel handler for that system call.

An application also transfers control to the kernel when it executes a load instruction to an address that is not read-enabled, or it executes a store instruction to an address that is not write-enabled. On such accesses, the MMU triggers a page fault, and the exception handling mechanism transfers control to the kernel's page fault handler. The MMU retries the faulting instruction after the page fault handler returns.

When the application executes a load or store instruction to an address that is resident in memory, and the access is allowed by the page's protection, the MMU translates the virtual address to a physical address using the page table entry (PTE) for that address, which is stored in the page table pointed to by the page table base register (PTBR). The processor then accesses that physical address.

Items in [brackets] may or may not be called, depending on what processes are running. Note that there are two versions of vm_map : one in the application and one in the pager. The application- side vm_map is a system call wrapper and is called by the application process. When the application calls this function, the infrastructure invokes the corresponding system call in your pager. vm_yield is another system call wrapper and may cause the infrastructure to call vm_switch . The declarations for these functions are in vm_app.h and vm_pager.h .

We provide the software infrastructure shown in grey. This infrastructure emulates the MMU and exception-handling functionality of normal hardware, as well as physical memory and file and swap space. To use this infrastructure, each application that uses the pager must include vm_app.h and link with libvm_app.o , and your pager must include vm_pager.h and link with libvm_pager.o . Linking with these libraries enables application processes to communicate with the pager in the same way that applications on real hardware communicate with real operating systems. Applications issue load and store instructions (compiled from normal C++ variable accesses), and these are translated or faulted by the infrastructure exactly as in the above description of the MMU. The infrastructure transfers control on faults and system calls to the pager, which receives control via function calls. The infrastructure also invokes your pager's vm_init function when the pager starts.

3. Memory management hardware

 The system uses a single-level page table. A virtual address is composed of a virtual page number and a page offset:

When the application executes a load or store instruction, the MMU checks the protection bits of the virtual page being accessed, translates the virtual address to a physical address, and accesses the page. To carry out these tasks, the MMU uses information in the page table entry (PTE) for the virtual page being accessed. The array of PTEs for a process is called a page table. In this project, the page table stores an entry for each virtual page in the arena.

Page tables are stored in the kernel's address space. The system's page table base register (PTBR) contains the kernel address of the page table currently in use. The PTBR is a variable that is declared and defined by the infrastructure (but will be controlled by your pager).

vm_arena.h describes the arena of a process, which are the addresses in the range [ VM_ARENA_BASEADDR , VM_ARENA_BASEADDR + VM_ARENA_SIZE) .

The following portion of vm_pager.h describes a page table entry, page table, and page table base register. Note that the MMU for this project does not automatically maintain dirty and reference bits. Instead, these state bits will be maintained by your pager.

 

Attachments:

Related Questions

. Introgramming & Unix Fall 2018, CRN 44882, Oakland University Homework Assignment 6 - Using Arrays and Functions in C

DescriptionIn this final assignment, the students will demonstrate their ability to apply two ma

. The standard path finding involves finding the (shortest) path from an origin to a destination, typically on a map. This is an

Path finding involves finding a path from A to B. Typically we want the path to have certain properties,such as being the shortest or to avoid going t

. Develop a program to emulate a purchase transaction at a retail store. This program will have two classes, a LineItem class and a Transaction class. The LineItem class will represent an individual

Develop a program to emulate a purchase transaction at a retail store. Thisprogram will have two classes, a LineItem class and a Transaction class. Th

. SeaPort Project series For this set of projects for the course, we wish to simulate some of the aspects of a number of Sea Ports. Here are the classes and their instance variables we wish to define:

1 Project 1 Introduction - the SeaPort Project series For this set of projects for the course, we wish to simulate some of the aspects of a number of

. Project 2 Introduction - the SeaPort Project series For this set of projects for the course, we wish to simulate some of the aspects of a number of Sea Ports. Here are the classes and their instance variables we wish to define:

1 Project 2 Introduction - the SeaPort Project series For this set of projects for the course, we wish to simulate some of the aspects of a number of