Lecture: virtual memory Q&A
preparation
- read OSPP §9, Caching and Virtual Memory and §10, Applications of Memory Management
lab 2
boot_alloc(): what should it “allocate” & returnpgdir_walk(): why to allocate “a new page table page”- think twice whether an address is virtual or physical
- addresses from e820 - virtual or physical?
- if you are directly casting between integers and pointers, it’s often wrong!
- make sure you understand exercise 8, lab 1
- it’s easy to “understand” the high-level concepts; implementing them is another story
- go to office hours or schedule extra hours
virtual memory recap
- CPU asks OS to set up a data structure for VA → PA
- isolation: each process has its own address space
- per-process page table; flags (P/W/U/…)
- switch page table with process
- xv6
struct proc in proc.hscheduler() → switchuvm(p) → lcr3(v2p(p->pgdir))
- exercise: re-read chapter 2 of the xv6 book
- what’s the initial setup in
entrypgdir?
- focus on
kinit1() and kvmalloc() in main(), main.c
- a few questions to help you understand the code
- how does xv6 alloc/free physical memory
- how does the free list work
- in
walkpgdir(), are the permissions PTE_P | PTE_W | PTE_U correct (overly generous)?
example: page fault
volatile char *p = (volatile char *)0xcafebeef;
cprintf("XXX: %x\n", *p);
- add the above code to
i386_init and see what happens
- invalid read/write
- add two lines of code in JOS to read an invalid address
- with unpatched QEMU: reboot
- with patched QEMU: stop & print registers
- useful for debugging
- what are the values of CR2, CR3, EIP
examples: protection, virtualization, lazy allocation
- kernel runs in high virtual addresses
- kernel is mapped into every process’s address space - why?
- commonly used by today’s OSes - why high VAs for the kernel
- how does the kernel set this up - see comments in
kern/entry.S in JOS
- protect against stack overflow
- see Michael Barr’s Bookout v. Toyota, “Toyota’s major stack mistakes”
- trick: put a non-mapped page right below user stack
- JOS:
inc/memlayout.h
- implement null pointer dereference exception
- how would you implement this for Java, say
obj->field
- trick: put a non-mapped page at VA zero
- useful for catching program bugs
- limitations?
- limited physical memory
- applications need more memory than physical memory
- early days: two floppy drives
- strawman: applications store part of state to disk and load back later
- hard to write applications
- virtual memory: offer the illusion of a large, continuous memory
- swap space: OS pages out some pages to disk transparently
- distributed shared memory: access other machines’ memory across network
- memory-mapped files
mmap(): map files, read/write files like memory- simple programming interface
- when to page-in/page-out content?
- avoid data copying: send an mmaped file to network
- compare to using
read/write
- no data transfer from kernel to user
- copy-on-write fork
- strawman fork: copy all pages from parent to child
- observation: child and parent share most of the data
- mark pages as copy-on-write
- make a copy on page fault
- lab 4: you will implement user-level copy-on-write fork
- other sharing
- multiple guest OSes running inside the same hypervisor
- shared objects:
.so/.dll files
- grow stack on demand: see the in-class exercise
single-level paging
- x86 (32-bit): 4M single-level paging
- turn on the
PSE bit on CR4
- add the
PS bit to page entries
- VA → PA translation
- linear address
- bits 31-22: page directory index
- bits 21-0: offset into 4M page
- page directory entry
- bits 31-22: physical 4M page address
- bits 21-12: reserved
- bits 11-0: flags
- example
- xv6: used during booting - see
entrypgdir in main.c
- demo: turn your JOS into using 4M pages
- general concept: superpages (also known as huge pages or large pages)
four-level paging
