NOW Handout Page 1

CS258 S99 1 NOW Handout Page 1

CSE 820 Graduate Computer Architecture

Advanced Memory Hierarchy Virtual Machine Architecture

Based on slides by David Patterson University of California, Berkeley

CSE 820 2

Outline

• 11 Advanced Cache Optimizations • Memory Technology and DRAM optimizations • Virtual Machines • Xen VM: Design and Performance • Conclusion

CSE 820 3

Why More on Memory Hierarchy?

Processor-Memory Performance Gap Growing

CSE 820 4

Review: 6 Basic Cache Optimizations

• Reduce hit time 1. Give Reads Priority over Writes

• E.g., Read complete before earlier writes in write buffer 2. Avoid Address Translation during Cache Indexing

• Reduce Miss Penalty 3. Multilevel Caches

• Reduce Miss Rate 4. Larger Block size (Compulsory misses) 5. Larger Cache size (Capacity misses) 6. Higher Associativity (Conflict misses)

CSE 820 5

11 Advanced Cache Optimizations

• Reduce hit time 1. Small and simple

caches 2. Way prediction 3. Trace caches

• Increase cache bandwidth

4. Pipelined caches 5. Multibanked caches 6. Nonblocking caches

• Reduce Miss Penalty 7. Critical word first 8. Merging write buffers

• Reduce Miss Rate 9. Compiler optimizations

• Reduce miss penalty or miss rate via parallelism 10. Hardware prefetching 11. Compiler prefetching

6

1. Fast Hit times via Small and Simple Caches

• Index tag memory and then compare takes time • Small cache can help hit time since smaller memory takes

less time to index – E.g., L1 caches same size for 3 generations of AMD microprocessors:

K6, Athlon, and Opteron – Also L2 cache small enough to fit on chip with the processor avoids

time penalty of going off chip

• Simple ⇒ direct mapping – Can overlap tag check with data transmission since no choice

• Access time estimate for 90 nm using CACTI model 4.0 – Median ratios of access time relative to the direct-mapped caches are

1.32, 1.39, and 1.43 for 2-way, 4-way, and 8-way caches


CSE 820 7

2. Fast Hit times via Way Prediction

• How to combine fast hit time of Direct Mapped and have the lower conflict misses of 2-way SA cache?

• Way prediction: keep extra bits in cache to predict the “way,” or block within the set, of next cache access.

– Multiplexor is set early to select desired block, only 1 tag comparison performed that clock cycle in parallel with reading the cache data

– Miss ⇒ 1st check other blocks for matches in next clock cycle

• Accuracy ≈ 85% • Drawback: CPU pipeline is hard if hit takes 1 or 2 cycles

– Used for instruction caches vs. data caches

Hit Time

Way-Miss Hit Time Miss Penalty

CSE 820 8

3. Fast Hit times via Trace Cache (Pentium 4 only; and last time?)

• Find more instruction level parallelism? How: avoid translation from x86 to microops?

• Trace cache in Pentium 4 1. Dynamic traces of the executed instructions vs. static sequences of instructions as

determined by layout in memory » Built-in branch predictor

2. Cache the micro-ops vs. x86 instructions

» Decode/translate from x86 to micro-ops on trace cache miss + 1. ⇒ better utilize long blocks (don’t exit in middle of block, don’t enter

at label in middle of block) - 1. ⇒ complicated address mapping since addresses no longer aligned

to power-of-2 multiples of word size - 1. ⇒ instructions may appear multiple times in multiple dynamic

traces due to different branch outcomes

CSE 820 9

4: Increasing Cache Bandwidth by Pipelining

• Pipeline cache access to maintain bandwidth, but higher latency

• Instruction cache access pipeline stages: 1: Pentium 2: Pentium Pro through Pentium III 4: Pentium 4 - ⇒ greater penalty on mispredicted branches - ⇒ more clock cycles between the issue of the load

and the use of the data

CSE 820 10

5. Increasing Cache Bandwidth: Non-Blocking Caches

• Non-blocking cache or lockup-free cache allow data cache to continue to supply cache hits during a miss

– requires F/E bits on registers or out-of-order execution – requires multi-bank memories

• “hit under miss” reduces the effective miss penalty by working during miss vs. ignoring CPU requests

• “hit under multiple miss” or “miss under miss” may further lower the effective miss penalty by overlapping multiple misses

– Significantly increases the complexity of the cache controller as there can be multiple outstanding memory accesses

– Requires muliple memory banks (otherwise cannot support) – Penium Pro allows 4 outstanding memory misses

CSE 820 11

Value of Hit Under Miss for SPEC (old data)

• FP programs on average: AMAT= 0.68 -> 0.52 -> 0.34 -> 0.26 • Int programs on average: AMAT= 0.24 -> 0.20 -> 0.19 -> 0.19 • 8 KB Data Cache, Direct Mapped, 32B block, 16 cycle miss, SPEC 92

Integer Floating Point

“Hit under n Misses”

0->1 1->2 2->64 Base

CSE 820 12

6: Increasing Cache Bandwidth via Multiple Banks

• Rather than treat the cache as a single monolithic block, divide into independent banks that can support simultaneous accesses

– E.g., Sun T1 (“Niagara”) L2 has 4 banks

• Banking works best when accesses naturally spread themselves across banks ⇒ mapping of addresses to banks affects behavior of memory system

• Simple mapping that works well is “sequential interleaving”

– Spread block addresses sequentially across banks – E,g, if there 4 banks, Bank 0 has all blocks whose address modulo 4

is 0; bank 1 has all blocks whose address modulo 4 is 1; …


CSE 820 13

7. Reduce Miss Penalty: Early Restart and Critical Word First

• Don’t wait for full block before restarting CPU • Early restart—As soon as the requested word of the

block arrives, send it to the CPU and let the CPU continue execution

– Spatial locality ⇒ tend to want next sequential word, so not clear size of benefit of just early restart

• Critical Word First—Request the missed word first from memory and send it to the CPU as soon as it arrives; let the CPU continue execution while filling the rest of the words in the block

– Long blocks more popular today ⇒ Critical Word 1st Widely used

block

CSE 820 14

8. Merging Write Buffer to Reduce Miss Penalty

• Write buffer to allow processor to continue while waiting to write to memory

• If buffer contains modified blocks, the addresses can be checked to see if address of new data matches the address of a valid write buffer entry

• If so, new data are combined with that entry • Increases block size of write for write-through

cache of writes to sequential words, bytes since multiword writes more efficient to memory

• The Sun T1 (Niagara) processor, among many others, uses write merging

CSE 820 15

9. Reducing Misses by Compiler Optimizations

• McFarling [1989] reduced caches misses by 75% on 8KB direct mapped cache, 4 byte blocks in software

• Instructions – Reorder procedures in memory so as to reduce conflict misses – Profiling to look at conflicts(using tools they developed)

• Data – Merging Arrays: improve spatial locality by single array of compound

elements vs. two arrays – Loop Interchange: change nesting of loops to access data in order

stored in memory – Loop Fusion: Combine two independent loops that have same looping

and some variables overlap – Blocking: Improve temporal locality by accessing “blocks” of data

repeatedly vs. going down whole columns or rows

CSE 820 16

Merging Arrays Example

/* Before: 2 sequential arrays */ int val[SIZE];

int key[SIZE];

/* After: 1 array of stuctures */

struct merge {

int val;

int key;

}; struct merge merged_array[SIZE];

Reducing conflicts between val & key; improve spatial locality

CSE 820 17

Loop Interchange Example

/* Before */ for (k = 0; k < 100; k = k+1) for (j = 0; j < 100; j = j+1)

for (i = 0; i < 5000; i = i+1)

x[i][j] = 2 * x[i][j]; /* After */ for (k = 0; k < 100; k = k+1)

for (i = 0; i < 5000; i = i+1) for (j = 0; j < 100; j = j+1) x[i][j] = 2 * x[i][j];

Sequential accesses instead of striding through memory every 100 words; improved spatial locality

CSE 820 18

Loop Fusion Example

/* Before */ for (i = 0; i < N; i = i+1) for (j = 0; j < N; j = j+1)

a[i][j] = 1/b[i][j] * c[i][j]; for (i = 0; i < N; i = i+1)

for (j = 0; j < N; j = j+1) d[i][j] = a[i][j] + c[i][j];

/* After */

for (i = 0; i < N; i = i+1) for (j = 0; j < N; j = j+1)

{ a[i][j] = 1/b[i][j] * c[i][j]; d[i][j] = a[i][j] + c[i][j];}

2 misses per access to a & c vs. one miss per access; improve spatial locality


19

Blocking Example /* Before */ for (i = 0; i < N; i = i+1)

for (j = 0; j < N; j = j+1)

{r = 0;

for (k = 0; k < N; k = k+1){ r = r + y[i][k]*z[k][j];}; x[i][j] = r;

};

• Two Inner Loops: – Read all NxN elements of z[] – Read N elements of 1 row of y[] repeatedly – Write N elements of 1 row of x[]

• Capacity Misses a function of N & Cache Size: – 2N3 + N2 => (assuming no conflict; otherwise …)

• Idea: compute on BxB submatrix that fits CSE 820 20

Blocking Example

/* After */ for (jj = 0; jj < N; jj = jj+B)

for (kk = 0; kk < N; kk = kk+B)

for (i = 0; i < N; i = i+1)

for (j = jj; j < min(jj+B-1,N); j = j+1)

{r = 0; for (k = kk; k < min(kk+B-1,N); k = k+1) {

r = r + y[i][k]*z[k][j];}; x[i][j] = x[i][j] + r;

};

• B called Blocking Factor • Capacity Misses from 2N3 + N2 to 2N3/B +N2

• Conflict Misses Too?

CSE 820 21

Reducing Conflict Misses by Blocking

Conflict misses in caches not FA vs. Blocking size – Lam et al. [1991] a blocking factor of 24 had a fifth the misses vs. 48

despite both fit in cache 3/24/08 CS252 s06 Adv. Memory Hieriarchy 22

Summary of Compiler Optimizations to Reduce Cache Misses (by hand)

23

10. Reducing Misses by Hardware Prefetching of Instructions & Data

• Prefetching relies on having extra memory bandwidth that can be used without penalty

• Instruction Prefetching – Typically, CPU fetches 2 blocks on a miss: the requested block and the

next consecutive block. – Requested block is placed in instruction cache when it returns, and

prefetched block is placed into instruction stream buffer

• Data Prefetching – Pentium 4 can prefetch data into L2 cache from up to 8 streams from 8

different 4 KB pages – Prefetching invoked if 2 successive L2 cache misses to a page,

if distance between those cache blocks is < 256 bytes

CSE 820 24

11. Reducing Misses by Software Prefetching Data

• Data Prefetch – Load data into register (HP PA-RISC loads) – Cache Prefetch: load into cache

(MIPS IV, PowerPC, SPARC v. 9) – Special prefetching instructions cannot cause faults;

a form of speculative execution

• Issuing Prefetch Instructions takes time – Is cost of prefetch issues < savings in reduced misses? – Higher superscalar reduces difficulty of issue bandwidth


CSE 820 25

Compiler Optimization vs. Memory Hierarchy Search

• Compiler tries to figure out memory hierarchy optimizations

• New approach: “Auto-tuners” 1st run variations of program on computer to find best combinations of optimizations (blocking, padding, …) and algorithms, then produce C code to be compiled for that computer

• “Auto-tuner” targeted to numerical method – E.g., PHiPAC (BLAS), Atlas (BLAS),

Sparsity (Sparse linear algebra), Spiral (DSP), FFT-W

3/24/08 CS252 s06 Adv. Memory Hieriarchy 26 Reference

Best: 4x2

Mflop/s

Mflop/s

Sparse Matrix – Search for Blocking for finite element problem [Im, Yelick, Vuduc, 2005]

CSE 820 27

Best Sparse Blocking for 8 Computers

All possible column block sizes selected for 8 computers; How could compiler know?

Intel Pentium M

Sun Ultra 2, Sun Ultra 3,

AMD Opteron

IBM Power 4, Intel/HP Itanium

Intel/HP Itanium 2

IBM Power 3

8

4

2

1

1 2 4 8

row

blo

ck si

ze (r

)

column block size (c)

CSE 820 28

Technique Hit Time Band-width

Miss penalty

Miss rate

HW cost/ complexity Comment

Small and simple caches + – 0 Trivial; widely used Way-predicting caches + 1 Used in Pentium 4 Trace caches + 3 Used in Pentium 4 Pipelined cache access – + 1 Widely used Nonblocking caches + + 3 Widely used Banked caches + 1

Used in L2 of Opteron and Niagara

Critical word first and early restart + 2 Widely used Merging write buffer + 1

Widely used with write through

Compiler techniques to reduce cache misses + 0

Software is a challenge; some computers have compiler option

Hardware prefetching of instructions and data + + 2 instr., 3

data

Many prefetch instructions; AMD Opteron prefetches data

Compiler-controlled prefetching + + 3

Needs nonblocking cache; in many CPUs

CSE 820 29

Main Memory Background

• Performance of Main Memory: – Latency: Cache Miss Penalty

» Access Time: time between request and word arrives » Cycle Time: time between requests

– Bandwidth: I/O & Large Block Miss Penalty (L2)

• Main Memory is DRAM: Dynamic Random Access Memory – Dynamic since needs to be refreshed periodically (8 ms, 1% time) – Addresses divided into two halves (Memory as a 2D matrix):

» RAS or Row Access Strobe » CAS or Column Access Strobe

• Cache uses SRAM: Static Random Access Memory – No refresh (6 transistors/bit vs. 1 transistor

Size: DRAM/SRAM - 4-8, Cost/Cycle time: SRAM/DRAM - 8-16

CSE 820 30

Main Memory Deep Background

• “Out-of-Core”, “In-Core,” “Core Dump”? • “Core memory”? • Non-volatile, magnetic • Lost to 4 Kbit DRAM (today using 512Mbit DRAM) • Access time 750 ns, cycle time 1500-3000 ns


CSE 820 31

DRAM logical organization (4 Mbit)

• Square root of bits per RAS/CAS

Column Decoder

Sense Amps & I/O

Memory Array (2,048 x 2,048)

A0…A1 0

… 1 1 D

Q

W ord Line Storage Cell

CSE 820 32

Quest for DRAM Performance

1. Fast Page mode – Add timing signals that allow repeated accesses to row buffer

without another row access time – Such a buffer comes naturally,

as each array will buffer 1024 to 2048 bits for each access

2. Synchronous DRAM (SDRAM) – Add a clock signal to DRAM interface, so that the repeated

transfers would not bear overhead to synchronize with DRAM controller

3. Double Data Rate (DDR SDRAM) – Transfer data on both the rising edge and falling edge of the

DRAM clock signal ⇒ doubling the peak data rate – DDR2 lowers power by dropping the voltage from 2.5 to 1.8 volts

+ offers higher clock rates: up to 400 MHz – DDR3 drops to 1.5 volts + higher clock rates: up to 800 MHz

• Improved Bandwidth, not Latency

33

DRAM name based on Peak Chip Transfers / Sec DIMM name based on Peak DIMM MBytes / Sec

Stan-dard Clock Rate

(MHz) M

transfers / second DRAM

Name Mbytes/s/ DIMM DIMM

Name DDR 133 266 DDR266 2128 PC2100 DDR 150 300 DDR300 2400 PC2400 DDR 200 400 DDR400 3200 PC3200

DDR2 266 533 DDR2-533 4264 PC4300 DDR2 333 667 DDR2-667 5336 PC5300 DDR2 400 800 DDR2-800 6400 PC6400 DDR3 533 1066 DDR3-1066 8528 PC8500 DDR3 666 1333 DDR3-1333 10664 PC10700 DDR3 800 1600 DDR3-1600 12800 PC12800 x 2 x 8

Fast

est f

or s

ale

4/06

($12

5/G

B)

34

Need for Error Correction!

• Motivation: – Failures/time proportional to number of bits! – As DRAM cells shrink, more vulnerable

• Went through period in which failure rate was low enough without error correction that people didn’t do correction

– DRAM banks too large now – Servers always corrected memory systems

• Basic idea: add redundancy through parity bits – Common configuration: Random error correction

» SEC-DED (single error correct, double error detect) » One example: 64 data bits + 8 parity bits (11% overhead)

– Really want to handle failures of physical components as well » Organization is multiple DRAMs/DIMM, multiple DIMMs » Want to recover from failed DRAM and failed DIMM! » “Chip kill” handle failures width of single DRAM chip

CSE 820 35

Introduction to Virtual Machines

• VMs developed in late 1960s – Remained important in mainframe computing over the years – Largely ignored in single user computers of 1980s and 1990s

• Recently regained popularity due to – increasing importance of isolation and security in modern

systems, – failures in security and reliability of standard operating

systems, – sharing of a single computer among many unrelated users, – and the dramatic increases in raw speed of processors, which

makes the overhead of VMs more acceptable

CSE 820 36

What is a Virtual Machine (VM)? • Broadest definition includes all emulation

methods that provide a standard software interface, such as the Java VM

• “(Operating) System Virtual Machines” provide a complete system level environment at binary ISA

– Here assume ISAs always match the native hardware ISA – E.g., IBM VM/370, VMware ESX Server, and Xen

• Present illusion that VM users have entire computer to themselves, including a copy of OS

• Single computer runs multiple VMs, and can support a multiple, different OSes

– On conventional platform, single OS “owns” all HW resources – With a VM, multiple OSes all share HW resources

• Underlying HW platform is called the host, and its resources are shared among the guest VMs


CSE 820 37

Virtual Machine Monitors (VMMs)

• Virtual machine monitor (VMM) or hypervisor is software that supports VMs

• VMM determines how to map virtual resources to physical resources

• Physical resource may be time-shared, partitioned, or emulated in software

• VMM is much smaller than a traditional OS; – isolation portion of a VMM is ≈ 10,000 lines of code

CSE 820 38

VMM Overhead?

• Depends on the workload • User-level processor-bound programs (e.g.,

SPEC) have zero-virtualization overhead – Runs at native speeds since OS rarely invoked

• I/O-intensive workloads ⇒ OS-intensive ⇒ execute many system calls and privileged instructions ⇒ can result in high virtualization overhead

– For System VMs, goal of architecture and VMM is to run almost all instructions directly on native hardware

• If I/O-intensive workload is also I/O-bound ⇒ low processor utilization since waiting for I/O ⇒ processor virtualization can be hidden ⇒ low virtualization overhead

CSE 820 39

Other Uses of VMs

• Focus here on protection • 2 Other commercially important uses of VMs 1. Managing Software

– VMs provide an abstraction that can run the complete SW stack, even including old OSes like DOS

– Typical deployment: some VMs running legacy OSes, many running current stable OS release, few testing next OS release

2. Managing Hardware – VMs allow separate SW stacks to run independently yet share

HW, thereby consolidating number of servers » Some run each application with compatible version of OS

on separate computers, as separation helps dependability – Migrate running VM to a different computer

» Either to balance load or to evacuate from failing HW CSE 820 40

Requirements of a Virtual Machine Monitor

• A VM Monitor – Presents a SW interface to guest software, – Isolates state of guests from each other, and – Protects itself from guest software (including guest OSes)

• Guest software should behave on a VM exactly as if running on the native HW

– Except for performance-related behavior or limitations of fixed resources shared by multiple VMs

• Guest software should not be able to change allocation of real system resources directly

• Hence, VMM must control ≈ everything even though guest VM and OS currently running is temporarily using them

– Access to privileged state, Address translation, I/O, Exceptions and Interrupts, …

CSE 820 41

Requirements of a Virtual Machine Monitor

• VMM must be at higher privilege level than guest VM, which generally run in user mode ⇒ Execution of privileged instructions handled by VMM

• E.g., Timer interrupt: VMM suspends currently running guest VM, saves its state, handles interrupt, determine which guest VM to run next, and then load its state – Guest VMs that rely on timer interrupt provided with virtual

timer and an emulated timer interrupt by VMM • Requirements of system virtual machines are

≈ same as paged-virtual memory: 1. At least two processor modes, system and user 2. Privileged subset of instructions available only in system

mode, trap if executed in user mode 1. All system resources controllable only via these

instructions CSE 820 42

ISA Support for Virtual Machines

• If VMs are planned for during design of ISA, easy to reduce instructions that must be executed by a VMM and how long it takes to emulate them

– Since VMs have been considered for desktop/PC server apps only recently, most ISAs were created without virtualization in mind, including 80x86 and most RISC architectures

• VMM must ensure that guest system only interacts with virtual resources ⇒ conventional guest OS runs as user mode program on top of VMM

– If guest OS attempts to access or modify information related to HW resources via a privileged instruction--for example, reading or writing the page table pointer--it will trap to the VMM

• If not, VMM must intercept instruction and support a virtual version of the sensitive information as the guest OS expects (examples soon)


CSE 820 43

Impact of VMs on Virtual Memory

• Virtualization of virtual memory if each guest OS in every VM manages its own set of page tables?

• VMM separates real and physical memory – Makes real memory a separate, intermediate level between virtual

memory and physical memory – Some use the terms virtual memory, physical memory, and

machine memory to name the three levels – Guest OS maps virtual memory to real memory via its page tables,

and VMM page tables map real memory to physical memory

• VMM maintains a shadow page table that maps directly from the guest virtual address space to the physical address space of HW

– Rather than pay extra level of indirection on every memory access – VMM must trap any attempt by guest OS to change its page table

or to access the page table pointer CSE 820 44

ISA Support for VMs & Virtual Memory

• IBM 370 architecture added additional level of indirection that is managed by the VMM

– Guest OS keeps its page tables as before, so the shadow pages are unnecessary

• To virtualize software TLB, VMM manages the real TLB and has a copy of the contents of the TLB of each guest VM

– Any instruction that accesses the TLB must trap – TLBs with Process ID tags support a mix of entries from

different VMs and the VMM, thereby avoiding flushing of the TLB on a VM switch

CSE 820 45

Impact of I/O on Virtual Memory

• Most difficult part of virtualization – Increasing number of I/O devices attached to the computer – Increasing diversity of I/O device types – Sharing of a real device among multiple VMs, – Supporting the myriad of device drivers that are required,

especially if different guest OSes are supported on the same VM system

• Give each VM generic versions of each type of I/O device driver, and let VMM to handle real I/O

• Method for mapping virtual to physical I/O device depends on the type of device: – Disks partitioned by VMM to create virtual disks for guest VMs – Network interfaces shared between VMs in short time slices,

and VMM tracks messages for virtual network addresses to ensure that guest VMs only receive their messages

CSE820 46

Example: Xen VM • Xen: Open-source System VMM for 80x86 ISA

– Project started at University of Cambridge, GNU license model • Original vision of VM is running unmodified OS

– Significant wasted effort just to keep guest OS happy • “paravirtualization” - small modifications to guest OS to

simplify virtualization Three Examples of paravirtualization in Xen:

1. To avoid flushing TLB when invoke VMM, Xen mapped into upper 64 MB of address space of each VM

2. Guest OS allowed to allocate pages, just check that didn’t violate protection restrictions

3. To protect the guest OS from user programs in VM, Xen takes advantage of 4 protection levels available in 80x86

» Most OSes for 80x86 keep everything at privilege levels 0 or at 3. » Xen VMM runs at the highest privilege level (0) » Guest OS runs at the next level (1) » Applications run at the lowest privilege level (3)

CSE 820 47

Xen changes for paravirtualization • Port of Linux to Xen changed ≈ 3000 lines,

or ≈ 1% of 80x86-specific code – Does not affect application-binary interfaces of guest OS

• OSes supported in Xen 2.0 OS Runs as host OS Runs as guest OS

Linux 2.4 Yes Yes Linux 2.6 Yes Yes NetBSD 2.0 No Yes NetBSD 3.0 Yes Yes Plan 9 No Yes FreeBSD 5 No Yes

http://wiki.xensource.com/xenwiki/OSCompatibility

CSE 820 48

Xen and I/O

• To simplify I/O, privileged VMs assigned to each hardware I/O device: “driver domains”

– Xen Jargon: “domains” = Virtual Machines

• Driver domains run physical device drivers, although interrupts still handled by VMM before being sent to appropriate driver domain

• Regular VMs (“guest domains”) run simple virtual device drivers that communicate with physical devices drivers in driver domains over a channel to access physical I/O hardware

• Data sent between guest and driver domains by page remapping


CSE 820 49

Xen Performance Performance relative to native Linux for Xen for 6 benchmarks

from Xen developers

Slide 40: User-level processor-bound programs? I/O-intensive workloads? I/O-Bound I/O-Intensive?

50

Xen Performance, Part II Subsequent study noticed Xen experiments based on 1

Ethernet network interface card (NIC), and single NIC was a performance bottleneck

CSE 820 51

Xen Performance, Part III

1. > 2X instructions for guest VM + driver VM 2. > 4X L2 cache misses 3. 12X – 24X Data TLB misses

CSE 820 52

Xen Performance, Part IV

1. > 2X instructions: page remapping and page transfer between driver and guest VMs and due to communication between the 2 VMs over a channel

2. 4X L2 cache misses: Linux uses zero-copy network interface that depends on ability of NIC to do DMA from different locations in memory 1. Since Xen does not support “gather DMA” in its virtual network

interface, it can’t do true zero-copy in the guest VM

3. 12X – 24X Data TLB misses: 2 Linux optimizations 1. Superpages for part of Linux kernel space, and 4MB pages

lowers TLB misses versus using 1024 4 KB pages. Not in Xen 2. PTEs marked global are not flushed on a context switch, and

Linux uses them for its kernel space. Not in Xen

4. Future Xen may address 2. and 3., but 1. inherent?

Popek and Goldberg virtualization requirements

A set of sufficient conditions for a computer architecture to efficiently support system virtualization.

Even though the requirements are derived under simplifying assumptions, they still represent a convenient way of determining whether a computer architecture supports efficient virtualization and provide guidelines for the design of virtualized computer architectures.

1 Gerald J. Popek & Robert P. Goldberg, "Formal Requirements for Virtualizable Third Generation Architectures”, 1974.

CSE 820 53

Properties of Interest

• Equivalence – A program running under the VMM should exhibit a

behavior essentially identical to that demonstrated when running on an equivalent machine directly.

• Resource control – The VMM must be in complete control of the virtualized

resources.

• Efficiency – A statistically dominant fraction of machine instructions

must be executed without VMM intervention.

CSE 820 54


Three Types of Instructions

• Privileged instructions – Those that trap if the processor is in user mode and do not

trap if it is in system mode.

• Control sensitive instructions – Those that attempt to change the configuration of resources

in the system.

• Behavior sensitive instructions – Those whose behavior or result depends on the configuration

of resources (the content of the relocation register or the processor's mode).

CSE 820 55

Theorems

• Theorem 1. A VMM may be constructed, if the set of sensitive instructions for that computer is a subset of the set of privileged instructions.

– Intuitively, the theorem states that to build a VMM it is sufficient that all instructions that could affect the correct functioning of the VMM (sensitive instructions) always trap and pass control to the VMM. This guarantees the resource control property. Non privileged instructions must instead be executed natively (i.e., efficiently). The holding of the equivalence property also follows.

• Theorem 2. A computer is recursively virtualizable (can run a copy of itself), if

1. it is virtualizable and 2. a VMM without any timing dependencies can be constructed for it.

CSE 820 56

Intel VT (virtualization technology)

• The principal role of the VMM is to arbitrate access to the underlying physical host platform resources so that these resources can be shared among multiple OSs that are "guests" of the VMM. The VMM presents to each guest OS a set of virtual platform interfaces that constitute a virtual machine (VM).

CSE 820 57

• Intel microprocessors (both IA-32 and Itanium® architecture) provide protection based on the concept of a 2–bit privilege level, using 0 for most-privileged software and 3 for least-privileged. The privilege level determines whether privileged instructions, which control basic CPU functionality, can execute without fault. It also controls address-space accessibility based on the configuration of the processor's page tables and, for IA-32, segment registers. Most IA software uses only privilege levels 0 and 3.

• For an OS to control the CPU, some of its components must run with privilege level 0. Because a VMM cannot allow a guest OS such control, a guest OS cannot execute at privilege level 0. Thus, VMMs running on either IA-32 or Itanium processors must use ring deprivileging, a technique that runs all guest software at a privilege level greater than 0. A guest OS could be deprivileged in two distinct ways: it could run either at privilege level 1 (the 0/1/3 model) or at privilege level 3 (the 0/3/3 model).

• Although the 0/1/3 model supports simpler VMMs, it cannot be used for guests on IA-32 processors in 64-bit mode.

CSE 820 58

Ring Aliasing • Ring aliasing refers to problems that arise when software

is run at a privilege level other than the privilege level for which it was written.

• An example in IA-32 involves the CS segment register, which points to the code segment. If the PUSH instruction is executed with the CS segment register, the contents of that register (which include the current privilege level) is pushed on the stack. Similarly, the Itanium instruction br.call saves the current privilege level into the ppl field of the Previous Function State (PFS) register, which can be read at any privilege level. In either case, a guest OS could easily determine that it is not running at privilege level 0.

CSE 820 59

Address-Space Compression • Address-space compression refers to the challenges of protecting parts of the

virtual-address space and supporting guest accesses to them. • OSs expect to have access to the processor's full virtual-address space (known as

the linear-address space in IA-32). A VMM must reserve for itself some portion of the guest's virtual-address space. It could run entirely within the guest's virtual-address space, which allows it easy access to guest data, but the VMM's instructions and data structures would use a substantial amount of the guest's virtual-address space.

• Alternatively, the VMM can run in a separate address space, but even in that case, the VMM must use a minimal amount of the guest's virtual-address space for the control structures that manage transitions between guest software and the VMM. For IA-32, these structures include the interrupt-descriptor table (IDT) and the global-descriptor table (GDT), which reside in the linear-address space. For the Itanium architecture, the structures include the interruption vector table (IVT), which resides in the virtual-address space.

• The VMM must prevent guest access to those portions of the guest's virtual-address space that the VMM is using. Otherwise, the VMM's integrity could be compromised (if the guest can write to those portions) or the guest could detect that it is running in a VM (if it can read those portions). Guest attempts to access these portions of the address space must generate transitions to the VMM, which can emulate or otherwise support them.

CSE 820 60


Non-Faulting Access to Privileged State • Privilege-based protection prevents unprivileged software from accessing certain

components of CPU state. In most cases, attempted accesses result in faults, allowing a VMM to emulate the desired guest instruction. However, the IA-32 and Itanium architectures both include instructions that access privileged state and do not fault when executed with insufficient privilege. For example, the IA-32 registers GDTR, IDTR, LDTR, and TR contain pointers to data structures that control CPU operation. Software can execute the instructions that write to, or load, these registers (LGDT, LIDT, LLDT, and LTR) only at privilege level 0. However, software can execute the instructions that read, or store, from these registers (SGDT, SIDT, SLDT, and STR) at any privilege level. If the VMM maintains these registers with unexpected values, a guest OS using the latter instructions could determine that it does not have full control of the CPU.

• Another example pertains to the page-table address (PTA) register of the Itanium architecture, a field that references the base address of the virtual hash page table (VHPT). The instruction mov to cr.PTA is the normal way to access this register, and software can execute it only at privilege level 0. However, the thash instruction indirectly exposes all or part of the VHPT base address, and software can execute it at any privilege level. If the VMM maintains the VHPT at a different address than the guest OS expects, a guest OS using the thash instruction could determine that it does not have full control of the CPU.

CSE 820 61

Adverse Impact on Guest System Calls

Ring deprivileging can interfere with the effectiveness of facilities in the IA-32 architecture that accelerate the delivery and handling of transitions to OS software. The IA-32 SYSENTER and SYSEXIT instructions support low-latency system calls. SYSENTER always effects a transition to privilege level 0, and SYSEXIT faults if executed outside that ring.

Ring deprivileging thus has the following implications: – Executions of SYSENTER by a guest application cause transitions to the VMM

and not to the guest OS. The VMM must emulate every guest execution of SYSENTER.

– Executions of SYSEXIT by a guest OS cause faults to the VMM. The VMM must emulate every guest execution of SYSEXIT.

CSE 820 62

Interrupt Virtualization • Providing support for external interrupts, especially regarding interrupt masking,

presents some specific challenges to VMM design. Both the IA-32 and Itanium architectures provide mechanisms for masking external interrupts thus preventing their delivery when the OS is not ready for them. IA-32 uses the interrupt flag (IF) in the EFLAGS register to control interrupt masking; the Itanium architecture uses the i bit in the processor status register (PSR) to provide this function. In both cases, a value of 0 indicates that interrupts are masked.

• A VMM will likely manage external interrupts and deny guest software the ability to control interrupt masking. Existing protection mechanisms allow such denial of control by ensuring that guest attempts to control interrupt masking fault in the context of ring deprivileging. Such faulting can cause problems because some OSs frequently mask and unmask interrupts. Intercepting every guest attempt to do so could significantly affect system performance.

• Even if it were possible to prevent guest modifications of interrupt masking without intercepting each attempt, challenges would remain when a VMM has a "virtual interrupt" to deliver to a guest. A virtual interrupt should be delivered only when the guest has unmasked interrupts. To deliver virtual interrupts in a timely way, a VMM should intercept some but not all attempts by a guest to modify interrupt masking. Doing so could significantly complicate the design of a VMM.

CSE 820 63

Ring Compression

• Ring deprivileging uses privilege-based mechanisms to protect the VMM from guest software. IA-32 includes two such mechanisms: segment limits and paging. Because segment limits do not apply in 64-bit mode, paging must be used in this mode. Because IA-32 paging does not distinguish privilege levels 0–2, the guest OS must run at privilege level 3 (the 0/3/3 model). Thus, the guest OS runs at the same privilege level as guest applications and is not protected from them. This problem is called ring compression.

CSE 820 64

Frequent Access to Privileged Resources

• A VMM may prevent guest access to privileged resources by forcing attempts at such accesses to fault. Even when this ensures correct behavior, performance may be compromised if the frequency of such faults is excessive.

• In the IA-32 and Itanium architectures, an example involves the task-priority register (TPR). For the IA-32 architecture, this register is located in the advanced programmable interrupt controller (APIC), and for the Itanium architecture, it is one of the control registers. Because it controls interrupt prioritization, a VMM must not allow a guest OS access to the TPR. However, some OSs perform such accesses with very high frequency. These accesses require VMM intervention only if they cause the TPR to drop below a value determined by the VMM.

CSE 820 65

VMM in software • VMM designers have developed creative techniques for modifying guest

software (source or binary). Denali [5] and Xen* [2] are examples of VMMs that use source-level modifications in a technique called paravirtualization. Developers of these VMMs modify the source code of a guest OS to create an interface that is easier to virtualize. Paravirtualization offers high performance and does not require changes to guest applications. A disadvantage of paravirtualization is that it limits the range of supported OSs; VMMs that rely on paravirtualization cannot support an OS whose source code the VMM's developers have not modified.

• A VMM can support unmodified OSs by transforming guest-OS binaries on-the-fly to handle virtualization-sensitive operations. VMMs that use such binary-translation techniques include those developed by VMware [4] as well as Virtual PC* and Virtual Server* from Microsoft. [3]. Such VMMs support a broader range of OSs than VMMs that use paravirtualization.

• A central design goal for Intel® VT has been to eliminate the need for CPU paravirtualization and binary translation techniques, to simplify the implementation of robust VMMs that can support a broad range of unmodified guest OSs, and to maintain high levels of performance CSE 820 66


VT-x Architecture Overview • VT-x augments IA-32 with two new forms of CPU operation: VMX root operation and

VMX non-root operation. VMX root operation is intended for use by a VMM, and its behavior is very similar to that of IA-32 without VT-x. VMX non-root operation provides an alternative IA-32 environment controlled by a VMM and designed to support a VM. Both forms of operation support all four privilege levels, allowing guest software to run at its intended privilege level, and providing a VMM with the flexibility to use multiple privilege levels.

• VT-x defines two new transitions: a transition from VMX root operation to VMX non-root operation is called a VM entry, and a transition from VMX non-root operation to VMX root operation is called a VM exit. VM entries and VM exits are managed by a new data structure called the virtual-machine control structure (VMCS). The VMCS includes a guest-state area and a host-state area, each of which contains fields corresponding to different components of processor state. VM entries load processor state from the guest-state area. VM exits save processor state to the guest-state area and then load processor state from the host-state area.

• Processor operation is changed substantially in VMX non-root operation. The most important change is that many instructions and events cause VM exits. Some instructions (e.g., INVD) cause VM exits unconditionally and thus can never be executed in VMX non-root operation. Other instructions (e.g., INVLPG) and all events can be configured to do so conditionally using VM-execution control fields in the VMCS.

CSE 820 67

Guest-State Area • The guest-state area of the VMCS is used to contain elements of the state of virtual

CPU associated with that VMCS.

• For proper VMM operation, certain registers must be loaded by every VM exit. These include those IA-32 registers that manage operation of the processor, such as the segment registers (to map from logical to linear addresses), CR3 (to map from linear to physical addresses), IDTR (for event delivery), and many others. The guest-state area contains fields for these registers so that their values can be saved as part of each VM exit.

• In addition, the guest-state area contains fields corresponding to elements of processor state that are not held in any software-accessible register. One of these elements is the processor's interruptibility state, which indicates whether external interrupts are temporarily masked (e.g., due to execution of the MOV-SS instruction) and whether non-maskable interrupts (NMIs) are masked because software is handling an earlier NMI.

• The guest-state area does not contain fields corresponding to registers that can be saved and loaded by the VMM itself (e.g., the general-purpose registers). Exclusion of such registers improves the performance of VM entries and VM exits. Software can manage these additional registers more efficiently as it knows better than the CPU when they need to be saved and loaded.

3/24/08 CS252 s06 Adv. Memory Hieriarchy 68

VM-Execution Control Fields • The VMCS contains a number of fields that control VMX non-root

operation by specifying the instructions and events that cause VM exits. In this section, we present some of these controls.

• The VMCS includes controls that support interrupt virtualization:

– External-interrupt exiting. When this control is set, all external interrupts cause VM exits; in addition, the guest is not able to mask these interrupts (e.g., interrupts are not masked if EFLAGS.IF=0).

– Interrupt-window exiting. When this control is set, a VM exit occurs whenever guest software is ready to receive interrupts (e.g., when EFLAGS.IF=1).

– Use TPR shadow. When this control is set, accesses to the APIC's TPR through control register CR8 (available only in 64-bit mode) are handled in a special way: executions of MOV CR8 access a TPR shadow referenced by a pointer in the VMCS. The VMCS also includes a TPR threshold; a VM exit occurs after any instruction that reduces the TPR shadow below the TPR threshold.

CSE 820 69

• There are also VM-execution control fields that support efficient virtualization of the IA-32 control registers CR0 and CR4. These registers each comprise a set of bits controlling processor operation. A VMM may wish to retain control of some of these bits (e.g., those that manage paging) but not others (e.g., those that control floating-point instructions). The VMCS includes, for each of these registers, a guest/host mask that a VMM can use to indicate which bits it wants to protect. Guest writes can freely modify the unmasked bits, but an attempt to modify a masked bit causes a VM exit. The VMCS also includes, for each of these registers, a read shadow whose value is returned to guest reads of the register.

CSE 820 70

• To support VMM flexibility, the VMCS includes bitmaps that allow a VMM selectivity regarding the causes of some VM exits. The following items detail three of these:

– Exception bitmap: This field contains 32 entries for the IA-32 exceptions. It allows a VMM to specify which exceptions should cause VM exits and which should not. For page faults, further selectivity is supported based on a fault's error code.

– I/O bitmaps: These bitmaps contain one entry for each port in the 16-bit I/O space. An I/O instruction (e.g., IN) causes a VM exit if it attempts to access a port whose entry is set in the I/O bitmaps.

– MSR bitmaps: These bitmaps contain two entries (one for read, one for write) for each model-specific register (MSR) currently in use. An execution of RDMSR (or WRMSR) causes a VM exit if it attempts to read (or write) an MSR whose read bit (or write bit) is set in the MSR bitmaps

CSE 820 71

VMCS Details

• Like the IA-32 page tables, each VMCS is referenced with a physical (not linear) address. This eliminates the need to locate the VMCS in the guest's linear-address space (which, as noted below, may be different from that of the VMM). The format and layout of the VMCS in memory is not architecturally defined, allowing implementation-specific optimizations to improve performance in VMX non-root operation and to reduce the latency of VM entries and VM exits. VT-x defines a set of new instructions that allows software to access the VMCS in an implementation-independent manner.

CSE 820 72


Details of VM Entries and VM Exits • As noted earlier, VM entries load processor state from the guest-state area of the

VMCS. (Note that, because the state loaded includes CR3, the guest may run in a different linear-address space than the VMM.) In addition to loading guest state, VM entry can be optionally configured for event injection. The CPU effects this injection using the guest IDT to deliver an event (exception or interrupt) specified by the VMM, just as if it had actually occurred immediately after VM entry. This feature removes the need for a VMM to emulate delivery of these events.

• As noted above, VM exits save processor state into the guest-state area and then load processor state from the host-state area. (Again, because the state loaded includes CR3, the VMM may run in a different linear-address space than the guest.) This implies that all VM exits use a common entry point in the VMM. To simplify the design of a VMM, VT-x specifies that each VM exit save into the VMCS detailed information on the cause of the VM exit. Every VM exit records an exit reason (specifying, for example, which instruction caused the VM exit); many also record an exit qualification, which provides further details. For example, if a VM exit is caused by the MOV CR instruction, the exit reason would indicate "control-register access" and the exit qualification would identify the following: (1) the specific control register (e.g., CR0); (2) whether the MOV was to or from the register; and (3) which other register was the source or destination of the instruction.

• Each VM exit due to an IA-32 exception saves, in addition to information about the exception, information about any event (e.g., an external interrupt) that was being delivered at the time the exception occurred. This allows a VMM to virtualize nested exceptions properly. CSE 820 73

Address-Space Compression

• VT-x and VT-i provide two different techniques for solving address-space compression problems.

• With VT-x, every transition between guest software and the VMM can change the linear-address space, allowing guest software full use of its own address space. The VMX transitions are managed by the VMCS, which resides in the physical-address space, not the linear-address space.

CSE 820 74

Ring Aliasing and Ring Compression

• VT-x and VT-i allow a VMM to run guest software at its intended privilege level. This fact eliminates ring aliasing problems because instructions such as PUSH (of CS) and br.call cannot reveal that software is running in a VM. It also eliminates ring compression problems that arise when a guest OS executes at the same privilege level as guest applications.

CSE 820 75

Nonfaulting Access to Privileged State • VT-x and VT-i avoid the problem of providing nonfaulting

access to privileged state in two ways: by adding support that causes such accesses to transition to a VMM and by adding support that causes the state to become unimportant to a VMM.

• A VMM based on VT-x does not require control of the guest privilege level, and the VMCS controls the disposition of interrupts and exceptions. Thus, it can allow its guest access to the GDT, IDT, LDT, and TSS. VT-x allows guest software running at privilege level 0 to use the instructions LGDT, LIDT, LLDT, LTR, SGDT, SIDT, SLDT, and STR.

CSE 820 76

Guest System Calls

• Problems occur with the IA-32 instructions SYSENTER and SYSEXIT when a guest OS runs outside privilege level 0. With VT-x, a guest OS can run at privilege level 0, which eliminates problems associated with guest transitions.

CSE 820 77

Interrupt Virtualization • VT-x and VT-i both provide explicit support for interrupt virtualization.

• VT-x includes an external-interrupt exiting VM-execution control. When this control is set to 1, a VMM prevents guest control of interrupt masking without gaining control of every guest attempt to modify EFLAGS.IF. Similarly, VT-i includes a virtualization-acceleration field that prevents guest software from affecting interrupt masking and avoids making transitions to the VMM on every access to the PSR.i bit.

• VT-x also includes an interrupt-window exiting VM-execution control. When this control is set to 1, a VM exit occurs whenever guest software is ready to receive interrupts. A VMM can set this control when it has a virtual interrupt to deliver to a guest. Similarly, VT-i includes a PAL service that a VMM can use to register the vector of the pending virtual interrupt. When guest software executes instructions to unmask the pending interrupt, control is transferred to the VMM via the new virtual external interrupt vector.

CSE 820 78


Access to Hidden State

• VT-x and VT-i use different techniques to allow a VMM to manipulate components of guest state that are not represented in any software-accessible register.

• VT-x includes, in the guest-state area of the VMCS, fields corresponding to CPU state not represented in any software-accessible register. The processor loads values from these VMCS fields on every VM entry and saves into them on every VM exit. This provides the support necessary for preserving this state while the VMM is running or when changing VMs.

CSE 820 79

Frequent Access to Privileged Resources

• VT-x and VT-i allow a VMM to avoid the overhead of high-frequency guest accesses to the TPR register. A VMM can configure the VMCS (for VT-x) or use an acceleration (for VT-i) so that the VMM is invoked only when required: For VT-x this occurs when the value of the TPR shadow associated with the VMCS drops below that of a TPR threshold in the VMCS. For VT-i this occurs only when the writing of the TPR unmasks a virtual pending external interrupt for the guest.

CSE 820 80

VMM Usage of VT-x Architecture Features

CSE 820 81

Exception Handling • VT-x allows a VMM to configure any IA-32 exception to cause a VM exit

based on its vector (for page faults, further selectivity is supported based on a fault's error code). When handling such VM exits, a VMM has access to complete information about the exception, including its error code and any other fault-specific information (e.g., the faulting linear address for a page fault).

• The VMM may determine that the exception causing the VM exit should be handled by the guest OS. In these cases, the VMM can perform a VM entry to guest using event injection to deliver the exception.

• Alternatively, a VMM may respond to such a VM exit by eliminating the cause of the exception (e.g., by modifying the page tables to mark present a page that had not been present). In these cases, the VMM can then perform a VM entry to the guest, which will resume execution at the point at which the exception occurred. If the VM exit was due to a nested fault, the VMM can use event injection to deliver to the guest that event whose delivery encountered that nested fault

CSE 820 82

Interrupt Virtualization

• When a VMM has an interrupt to deliver to a guest OS, it can do so using event injection with the next VM entry. If guest software is not ready for an interrupt (e.g., because EFLAGS.IF = 0), the VMM can instead re-enter the guest having set the interrupt-window exiting VM-execution control. A VM exit will occur the next time the guest is ready for an interrupt. A VMM can then use event injection as part of the next VM entry.

CSE 820 83

Lazy Floating-Point State Processing

• The IA-32 architecture includes features by which an OS can avoid the time-consuming restoring the floating- point state when activating a user process that does not use the floating-point unit. It does this by setting the TS bit in control register CR0. If a user process then tries to use the floating-point unit, a device- not-available fault (exception 7 = #NM) occurs. The OS can respond to this by restoring the floating-point state and by clearing CR0.TS, which prevents the fault from recurring.

CSE 820 84


Future VT-x features • * NMI-window exiting. The interrupt-window exiting VM-execution

control (described earlier) causes a VM exit when a guest is ready for maskable external interrupts, allowing a VMM to deliver such interrupts in a timely way. NMI-window exiting provides corresponding support for non-maskable interrupts (NMIs), which are blocked by other conditions than those that block maskable external interrupts.

• * Virtual-processor identifiers (VPIDs). This feature allows a VMM to assign a different non-zero VPID to each virtual processor (the zero VPID is reserved for the VMM). The CPU can use VPIDs to tag translations in the TLBs. This feature eliminates the need for TLB flushes on every VM entry and VM exit and eliminates the adverse impact of those flushes on performance.

• * Extended page tables (EPT). When this feature is active, the ordinary IA-32 page tables (referenced by control register CR3) translate from linear addresses to guest-physical addresses. A separate set of page tables (the EPT tables) translate form guest-physical addresses to the host-physical addresses that are used to access memory. As a result, guest software can be allowed to modify its own IA-32 page tables and directly handle page faults. This allows a VMM to avoid the VM exits associated with page-table virtualization, which are a major source of virtualization overhead without EPT.

CSE 820 85

• http://www.intel.com/technology/itj/2006/v10i3/1-hardware/1-abstract.htm

CSE 820 86

CSE 820 87

And in Conclusion [1/2] …

• Memory wall inspires optimizations since so much performance lost there

– Reducing hit time: Small and simple caches, Way prediction, Trace caches

– Increasing cache bandwidth: Pipelined caches, Multibanked caches, Nonblocking caches

– Reducing Miss Penalty: Critical word first, Merging write buffers – Reducing Miss Rate: Compiler optimizations – Reducing miss penalty or miss rate via parallelism: Hardware

prefetching, Compiler prefetching

• “Auto-tuners” search replacing static compilation to explore optimization space?

• DRAM – Continuing Bandwidth innovations: Fast page mode, Synchronous, Double Data Rate

CSE 820 88

And in Conclusion [2/2] …

• VM Monitor presents a SW interface to guest software, isolates state of guests, and protects itself from guest software (including guest OSes)

• Virtual Machine Revival – Overcome security flaws of large OSes – Manage Software, Manage Hardware – Processor performance no longer highest priority

• Virtualization challenges for processor, virtual memory, and I/O

– Paravirtualization to cope with those difficulties

• Xen as example VMM using paravirtualization – 2005 performance on non-I/O bound, I/O intensive apps:

80% of native Linux without driver VM, 34% with driver VM

Documents

NOW Handout Page 1