Recap

n Goal: memory protection

n Fixed and fast: Rely on hardware support to translate every
memory reference to the actual physical address
Address Translation n Programmable: relies on a memory address translation
table
n On process switch, switch the translation table
Arvind Krishnamurthy n Install translations and let the program run
Spring 2001 n Who installs translations? Software
n Not user level software è need to distinguish between user and
kernel code è need for protected kernel mode
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 Address translation

n Goals
n implicit translation on every memory reference
n This lecture: how to implement the translation? n should be very fast
n protected from user’s faults

virtual physical
n Options
address address n Base and Bounds
Translation Box
CPU
n Segmentation
(MMU) physical n Paging
memory
n Multilevel translation
n Paged page tables
n Inverted page tables
Data read or write
(untranslated)

Base and Bounds Base and Bounds (contd.)

virtual memory physical memory
0
n Built in Cray-1
bound n A program can only access
code 6250 (base) physical memory in [base,
base+bound]
virtual address >
data n On a context switch:
error save/restore base, bound
bound + base registers
stack 6250+bound n Pros: Simple
n Cons: fragmentation; hard
physical address
to share (code but not data
Each program loaded into contiguous and stack); complex
regions of physical memory. memory allocation
Hardware cost: 2 registers, adder, comparator.

1
 Segmentation Segmentation (contd.)
n Motivation
separate the virtual address space into several segments so that we can Virtual address
n error
share some of them if necessary segment offset >
n A segment is a region of logically contiguous memory n Have a table of (seg, size)
seg size n Protection: each entry has
n Main idea: generalize base and bounds by allowing a table of
(nil,read,write)
base&bound pairs
n
..
(assume 2 bit segment ID, 12 bit segment offset) . n On a context switch:
save/restore the table or a
virtual segment # physical segment start segment size pointer to the table in kernel
memory
code (00) 0x4000 0x700
+ n Pros: Efficient, easy to share
data (01) 0 0x500
- (10) 0 0 n Cons: Complex management
stack (11) 0x2000 0x1000 physical address and fragmentation within a
segment

Segmentation example Segmentation example (cont’d)

(assume 2 bit segment ID, 12 bit segment offset) Virtual memory for strlen(x)
v-segment # p-segment segment physical memory physical memory for strlen(x)
start size
Main: 240 store 1108, r2
code (00) 0x4000 0x700 x: 108 a b c \0
0 244 store pc+8, r31
data (01) 0 0x500 …
- (10) 0 0 248 jump 360
4ff
stack (11) 0x2000 0x1000 24c Main: 4240 store 1108, r2
virtual memory … 4244 store pc+8, r31
2000 strlen: 360 loadbyte (r2), r3 4248 jump 360
0
… 424c
6ff 420 jump (r31) …
2fff
… strlen: 4360 loadbyte (r2), r3
1000
14ff …
4000 4420 jump (r31)
x: 1108 a b c \0
3000
46ff
…
…

3fff

Object file format Object file format (cont’d)

n Notice: char chArray[40];
n Segmentation table performs the task of runtime relocation static double x; Runtime segments:
n Loader’s task is simple; linker still needs to perform static relocation int y = 13;
BSS segment: chArray, x
static long z = 2001;
data segment: y, z
n Standard file format: ELF vs COFF code segment: all the machine instructions
main () { stack segment: local variables
type “man a.out” to see detail
int i = 3, j, *ip; heap segment: dynamic memory allocation
n magic number
n the header information
ip = malloc(sizeof(i)); The NOFF object file contains:
n a list of segments:
chArray[5] = i; code segment
(a) size needed for BSS segment (uninitialized variables)
y = 2.0 * z; data segment with initial values (initData)
(b) data segment (with initialized global and static variables) BSS segment with size only (uninitData)
}
(c) text segment (including executable instructions)
n optional relocation information 0 ------------------------> increasing offset
n optional symbol table and line number information
Header text (code) initialized data

2
 Address space in Nachos Paging
0xfff high address n Motivations
stack n both branch & bounds and segmentation still require fancy memory
segment 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)
data uninitialized data (Heap + BSS) n can we find something simple and easy
segment ----------------------
initialized data n Solution
main
n allocate physical memory in terms of fixed size chunks of memory,
memory or pages.
text
n Simpler because it allows use of a bitmap: 00111110000001100
segment
n each bit represents one page of physical memory
(code)
n 1 means allocated, 0 means unallocated
0x000 low address
address entry point for __start
translation

Paging (contd.) Paging example

physical memory
virtual memory 0
Virtual address page table size n Use a page table to translate
VPage # offset n Various bits in each entry
error a
n Context switch: similar to b 4
> i
the segmentation scheme c
Page table 4 j
n What should be the page d k
PPage# ... 3
size? 8
l
... e 1
.. n Pros: simple allocation, easy f
. to share
12
e
g
PPage# ... Cons: big page table and
f
n h g
cannot deal with internal page size: 4 bytes 16 h
i
fragmentation easily a
PPage # offset j b
k c
Physical address l d

Segmentation with paging Two-level Paging

Virtual address
Virtual address pte
dir table offset
Vseg # VPage # offset
..
.
Page table
seg size PPage# ...
... Directory .. ..
.. .. . .
. .
PPage# ...
Each segment has ..
> Each directory .
its own page table ! PPage # offset
entry points to a
error Physical address page table

3
 Two-level paging example How many PTEs do we need ?
n A logical address (on 32-bit machine with 4K page size) is divided n Worst case for 32-bit address machine
into: n # of processes × 220 (if page size is 4096 bytes)
n a page number consisting of 20 bits.
n a page offset consisting of 12 bits.
n Since the page table is paged, the page number is further divided
n What about 64-bit address machine?
into: n # of processes × 252
n a 10-bit page table number.
n a 10-bit page table offset.
n Thus, a logical address is as follows: n Solutions:
n Well, it is mostly unused…
page number page offset
n Paged page tables
pi p2 d

10 10 12
where pi is an index into the outer page table, and p2 is the
displacement within the page of the outer page table.

Paged Page Tables Inverted Page Tables

n So far, page tables have to be allocated linearly in memory
n Main idea
Physical One PTE for each physical
Virtual n
n Can we page them? address page frame
n That is, can we replace page table pointers with virtual addresses
address n Hash (Vpage, pid) to
n Implication: they can be swapped pid vpage offset k offset Ppage#
n Pros
Small page table for large
n Put page tables in a special segment that is translated but not n
address space
accessible to user programs (part of program’s virtual address space) 0
n Cons
n Lookup is difficult
n Page table for this segment alone is in physical memory n Overhead of managing hash
pid vpage k
chains, etc
n Segment table contains page table pointers that are virtual for some
segments, but physical for some others (used in MIPS and HPs) n-1
Inverted page table

Intel 80386 address translation Translation Look-aside Buffer

Virtual address
VPage # offset

VPage# PPage# ...

VPage# PPage# ... Miss
..
.
Real
VPage# PPage# ...
page
TLB
table
Hit
Speed up the PPage # offset
common case !
Physical address