More Paging

Address Translation With Paging

• multilevel page table
• with a single array, all entries must be allocated at once, but what if we use hierarchical arrays?
• indirection can save space when the allocated entries (pages) are sparse and adjacent
• does this always result in less memory used? what if every page gets accessed?

x86-64 Address Translation

• architecture specification defines format of the page table
• x86-64 page table: 4 level page table
1. Page Map Level 4 (PML4): top level page table, each entry stores the physical address of a PDPT
2. Page Directory Pointer Table (PDPT): 2nd level page table, each entry stores the physical address of a PDT
3. Page Directory Table (PDT): 3rd level page table, each entry stores the physical address of a PT
4. Page Table (PT): last level page table, each entry stores the physical address of a frame

• each table fits in a frame (4KB), each table entry is 8 bytes
• 4096 (table size) / 8 (entry size) = 512 (entries)
• 2^9 = 512, each level indexed with 9 bits of the virtual address
• what does the 8 byte page table entry look like?
• page table entry
  • bit 0-11 contain information about the page (bit 0: present, 1: writable, 2: user accessible)
  • bit 12-47 contain the physical page number of the frame
  • bit 48-63 contain either reserved field or other permission info about the page
  
• kernel sets up each page table entry with proper permissions
• access & dirty bits are set by the hardware when an access or a write is performed
• may also be modified by the kernel
• the kernel can use these bits to make paging policy decisions
• what errors may occur during a hardware page table walk?
• a NULL entry! may happen in any level of the page table, what does this mean?
• mismatching permission! user trying to read kernel address, writing to a read only page
• what can the hardware do?
• kill a process? how does it know what resources to clean up?
• when in doubt, transfer control to the OS!

Page Fault

• an exception that is raised by the hardware when something unexpected happens in the page table walk
• how should the kernel handle a page fault?
• identify and handle valid page faults
• stack or heap growth
• memory mapped files
• known permission mismatch
• memory pressure (access to swapped pages)
• terminate threads with invalid page faults
  • nullptr, random address in unallocated virtual memory
  • actual permission mismatch
• needs bookkeeping structures to track metadata for each page
• machine independent VM metadata vs machine dependent page table
• machine independent structures in xk: vspace, vregion, vpage_info
• track the size of each region (stack, heap, code), if a page is associated to any file, if a page is cow
• updated and referenced by the kernel when performing virtual memory related system calls and in handling page fault
• can be more complex, not on the critical path of each memory access
• machine dependent structures in xk: the x86-64 page table x86_64vm.c
• architecture specified page table, must be efficient for access
• vspaceupdate update a machine dependent page table based on the machine independent metadata