Base and Bounds virtual memory physical memory 0 Address Translation code 6250 (base) data Arvind Krishnamurthy bound Spring 2004 stack 6250+bound Each program loaded into contiguous regions of physical memory. Address Translation Recap Base and Bounds (contd.) n Goal: memory protection n Built in Cray-1 n Translate every memory reference to the actual physical n Hardware cost: two address bound registers, adder, n Programmable: relies on a memory address translation comparator è fast table virtual address > n On a context switch: n On process switch, switch the translation table error save/restore base, bound n Install translations and let the program run + base registers n Who installs translations? Software n What are the pros/cons of n Not user level software è need to distinguish between user and this approach? kernel code è need for protected kernel mode physical address n Hardware support for kernel mode: bit in a “processor status word” n When set, allows all kinds of protected operations n In kernel mode, all memory references are physical addresses Memory Protection Segmentation n Motivation virtual physical address address n separate the virtual address space into several segments so that we can Translation Box share some of them if necessary CPU n also allow holes in the address space (MMU) physical memory n A segment is a region of logically contiguous memory n Main idea: generalize base and bounds by allowing a table of base&bound pairs Data read or write (untranslated) (assume 2 bit segment ID, 12 bit segment offset) virtual segment # physical segment start segment size n This lecture: how to implement the translation? Should be fast n Options code (00) 0x4000 0x700 n Base and Bounds data (01) 0x0000 0x500 n Segmentation - (10) 0 0 n Paging stack (11) 0x2000 0x1000 n Multilevel translation 1 Segmentation example Object file format (assume 2 bit segment ID, 12 bit segment offset) n v-segment # p-segment segment physical memory Notice: start size n Segmentation table performs the task of runtime relocation code (00) 0x4000 0x700 n Loader’s task is simple; linker still needs to perform static relocation data (01) 0x0000 0x500 0 - (10) 0 0 stack (11) 0x2000 0x1000 n 500 Standard file format: ELF, COFF virtual memory type “man a.out” to see detail n magic number 0 2000 n the header information 700 n a list of segments: 3000 1000 (a) size needed for BSS segment (uninitialized variables) 1500 (b) data segment (with initialized global and static variables) (c) text segment (including executable instructions) 3000 4000 4700 n optional relocation information n optional symbol table and line number information 4000 Segmentation example (cont’d) Object file format (cont’d) Virtual memory for strlen(x) char chArray[40]; static double x; physical memory for strlen(x) Runtime segments: Main: 240 store 1108, r2 int y = 13; 244 store pc+8, r31 static long z = 2001; BSS segment: chArray, x x: 108 a b c \0 248 jump 360 data segment: y, z … 24c main () { code segment: all the machine instructions … int i = 3, j, *ip; stack segment: local variables Main: 4240 store 1108, r2 heap segment: dynamic memory allocation strlen: 360 loadbyte (r2), r3 4244 store pc+8, r31 … ip = malloc(sizeof(i)); 4248 jump 360 The NOFF object file contains: 420 jump (r31) chArray[5] = i; 424c code segment … y = 2.0 * z; … data segment with initial values (initData) } strlen: 4360 loadbyte (r2), r3 BSS segment with size only (uninitData) x: 1108 a b c \0 … … 0 ------------------------> increasing offset 4420 jump (r31) … Header text (code) initialized data Segmentation Implementation Address space in Nachos Virtual address 0xfff high address error stack segment offset > n Have a table of (seg, size) segment n Protection: each entry has seg size n (nil,read,write) data uninitialized data (Heap + BSS) . n On a context switch: segment ---------------------- . save/restore the table or a initialized data pointer to the table in kernel main memory memory n Have we addressed all of text + the requirements with this segment approach? (code) physical address 0x000 low address address entry point for __start translation 2 Paging How many PTEs do we need ? n Motivations n Worst case for 32-bit address machine 20 12 n both branch & bounds and segmentation still require fancy memory n # of processes ´ 2 (if page size is 4096 = 2 bytes) management (e.g., first fit, best fit, re-shuffling to coalesce free fragments if no single free space is big enough for a new segment) n What about 64-bit address machine? n can we find something simple and easy 52 n # of processes ´ 2 n Solution n allocate physical memory in terms of fixed size chunks of memory, n Question: how do we solve the huge page-table size or pages. problem? n Simpler because it allows use of a bitmap: 00111110000001100 n each bit represents one page of physical memory n 1 means allocated, 0 means unallocated Paging (contd.) Segmentation with paging n Use a page table to translate Virtual address page table size Virtual address n Context switch: similar to VPage # offset error the segmentation scheme Vseg # VPage # offset > n Question: What should be Page table the page size? Page table PPage# ... seg size PPage# ... ... ... n What are the pros/cons of . PPage# ... this scheme? PPage# ... Each segment has PPage # offset > its own page table PPage # offset Physical address error Physical address Paging example Paged Page Tables Physical memory Virtual memory n So far, page tables have to be allocated linearly in memory 0 n Can we page them? a n That is, can we replace page table pointers with virtual addresses b Page Table 4 i n Implication: they can be swapped c j 4 k d l 3 n 8 Put page tables in a special segment that is translated but not e 1 accessible to user programs (part of program’s virtual address space) e f 12 g f g h n Page table for this segment alone is in physical memory h i page size: 4 bytes 16 a j b n Segment table contains page table pointers that are virtual for some c k segments, but physical for some others (used in MIPS and HPs) d l 3 Assignment 2: Overview Assignment 2: user C program halt.c n Objectives n understand how system call really works #include "syscall.h" n understand how to support multiple address spaces n Problems int n implement a set of system calls main() n Exec, join on processes n Create, open, read, write, close on files { n Fork, yield for threads (optional – extra credit) Halt(); n implement multiprogramming /* not reached */ n use bitmap to find unused main memory } n setup the page table (translation is no longer identity) n data copying between user and kernel n n support argument passing for “exec” Note: we don’t use any standard C libraries (because they n support exec of “prog arg1 arg2” instead of exec prog wouldn’t work with the Nachos kernel) n should be easy Traditional OS Structure Assignment 2: user C program shell.c Application User #include "syscall.h” mode …… Application library while( 1 ) int main() { Write(prompt, 2, output); { SpaceId newProc; i = 0; Portable OS layer OpenFileId input = ConsoleInput; Kernel do { OpenFileId output = ConsoleOutput; mode Read(&buffer[i], 1, input); char prompt[2], ch, buffer[60]; Machine dependent layer } while( buffer[i++] != '\n' ); int i; buffer[--i] = '\0'; n How does Nachos’s structure fit into this model? prompt[0] = '-'; n Nachos is the portable OS layer – it simulates the hardware and machine- prompt[1] = '-'; if( i > 0 ) { dependent layer, and it simulates the execution of user programs running …… newProc = Exec(buffer); on top Join(newProc); n Can still use debugger, printf, etc. } n Can run normal UNIX programs concurrently with Nachos } } n Could run Nachos on real hardware by writing a machine-dependent layer Assignment 2: Overview (cont’d) The assembly stub file: start.s n Nachos execution overview: /* ------- System call stub for Halt ----- */ n user program (written in C): halt.c #include "syscall.h" .globl Halt n gcc cross compiler compiling halt.c into MIPS binary code .text .ent Halt .align 2 decstation-ultrix/bin/gcc halt.c start.s -o halt.coff Halt: coff2noff halt.coff halt /* ---------- a stub to main() ------- */ addiu $2,$0,SC_Halt .globl __start syscall Here, halt.coff is like the standard “a.out” file; .ent __start j $31 .end Halt “halt” is a simplified version of “halt.coff” designed for Nachos __start: /* must start at address 0 */ jal main /* ------- System call stub for Exit ------ */ move $4,$0 .globl Exit n nachos loads and runs the user code ( exec or progtest.cc ) jal Exit .ent Exit n initializing an address space /* if we return from main, exit(0) */ Exit: .end __start n set up the page table (mapping address space to physical memory) addiu $2,$0,SC_Exit n zero-ing all memory cells syscall j $31 n copy all segments in “noff” file (e.g., halt) into main memory .end Exit n call the MIPS simulator to run the user code gcc halt.c start.s -o halt.coff ................................ 4.