Memory Virtualization

Summary

• Memory Hierarchy
• Memory Subsystem Recall
• Memory Management and Hypervisor
• Memory Manager Zoomed Out
• Zooming Back In
• Shadow Page Table
• Efficient Mapping (Full Virtualization)
• Efficient Mapping (Para Virtualization)
• Dynamically Increasing Memory
• Sharing Memory Access Across Virtual Machines
  • VM Oblivious Page Sharing
• Memory Allocation Policies

Memory Hierarchy

Thorny issue

• Handling virtual memory to physical memory mapping is key functionality

Memory Subsystem Recall

Each application in its own protection domain

• And normally separate hardware address space

OS maintains pagetable on behalf of each process

• Maps virtual memory address (Virtual Page Number) to physicall address

Memory Management and Hypervisor

In each application on each OS on the hypervisor, we have separate protection domains.

Each guest OS’s protection domains are distinct from every other guest OS’s.

Memory Manager Zoomed Out

Each guest OS thinks it has contiguous memory, but, just like user processes, it’s actually mapped non-contiguously

Zooming Back In

Virtual Page Number (VPN) in process gets mapped to Physical Page Number (PPN) in OS.

PPN in OS gets mapped to Machine Page Number (MPN) in hardware.

• Kept in Shado Page Table (S-PT)

In paravirtualization, guest OS maintains S-PT

Shadow Page Table

In many architectures, CPU uses page table for address translation.

• After a TLB miss, mappings are looked up in PT

Hardware page table is really S-PT

Efficient Mapping (Full Virtualization)

Updating PageTable is a privileged operation, which results in a trap

• And ends up having the hypervisor updating S-PT
• Translations are installed into TLB/hardware PT

This means hypervisor can translate VPN to MPN directly

Efficient Mapping (Para Virtualization)

Shift burden to Guest OS

• maintain contiguous “physical memory”
• map to discontigous hardware pages

OS makes hypercalls to hypervisor to create page table, move page table, etc., then maintains its own mapping from VPN to this page table.

• Page faults and such are handled solely in guest OS

Dynamically Increasing Memory

You can rob one guest of memory to provide memory for others if its bursty

• Known as over-allocation or ballooning

Install special device driver in every guest OS

• Even fully virtualized
• Installed from and provides communication to hypervisor
• Inflate means request more memory from hypervisor
• Deflate means returns memory to hypervisor

Sharing Memory Access Across Virtual Machines

Can we share memory in a safe way acros VMs?

• Yes

Deduplication of code loaded into memory is potentially huge

• Only if running exact same versions of OS and apps across both VMs

This can be done by marking memory pages as Copy On Write (COW) so changes are not overwritten.

• Requires cooperation with guest OS and hypervisor

VM Oblivious Page Sharing

An alternative is to hash page frame contents

• Requires no intervention of guest OS
• Keep a reference count of hashes
• Scanning/moving pages is intensive task
  • Done as background jobs

Memory Allocation Policies

• Pure Share
  • Pay less, Get less
• Working-set
  • Give more to those who need it
• Dynamic idle-adjusted shares
  • Tax idle pages more than active pages
    • Typically some percentage, not all of idle pages
      • Reclaim most of idle memory
      • Allows for sudden bursts