A critical assault upon

1
A critical assault upon A Comparison of Software
and Hardware Techniques for x86
Virtualization Chris Smowton
2
Virtualisation in a slide

• Emulate running guest OS on real hardware
• Use actual hardware where you can
• Respond to cases where you can't with emulation
• Trap reactively (e.g. catch illegal instruction
  exception)
• Or adapt code to call out preemptively

3
Virtualising x86

• Two (major) sources of traps
• Inherently privileged instructions
• e.g. disable interrupts, enter kernel mode
• Easy to detect
• Writes to privileged memory
• e.g. write page table, segment table
• Could be caused by any ALU op (damn CISC)

4
Classical virtualisation and x86

• Classical virtualisation run guest in
  unprivileged processor mode
• Including kernel
• Take and handle exceptions on privileged ops
• But x86 Guest can tell it's being virtualised
• And Some instructions fail silently

5
Two ways out

• Software binary translation
• Rewrite those pesky instructions
• Opportunity to be cleverer than trap-and-emulate
• Hardware virtualisation
• i386 v1.1 introduce guest mode
• Extra pseudo-privileged CPU state
• Guest exception vectors, interrupt mask...
• Still trap page table alterations

6
Software BT (the vmware way)

• Rewrite guest kernel-mode code on demand
• Translate inherently privileged ops away
• Easy ones emulate without invoking VMM
• e.g. disable interrupts
• Hard ones call into VMM (cheaper than trap)
• Profile guest memory ops
• Often faults? Replace with VMM call
• Or, avoid call altogether!
• Sort of automatic PV OS generator

7
Guest MMU emulation

• Guest will try to write page tables
• However we detect that action
• Map guest VAs to pseudo-physical address
• VMM maps guest PPAs to (real) machine addresses
• Maintain a shadow page table mapping guest VAs
  to Mas
• Ensure shadow table always consistent with guest
  expectations

8
Software BT a neat example

• Process creation build a bunch of page tables
• Want to avoid fault on every PT write
• x86 new table entries not valid until TLB flush!
• Don't call up instead, save in SHM buffer
• On TLB flush, VMM processes the buffer
• Like Xen PV guests, only automatically generated

9
Hardware Virt (the Intel way)

• Replicate privileged processor state in VMCB
• New processor mode entered passing VMCB
• Disable interrupts? Write to VMCB
• Divide by zero? Check VMCB exc. Vector
• Enter kernel mode? Same.
• But, no guest MMU support in hardware
• Need software MMU emulation as before

10
Relative merits

• Hardware virt good at anything the VMCB supports
• Syscalls, interrupt mask...
• Software BT better at MMU ops
• Dynamically adapts
• Could do that for HW guys too...
• But they don't

11
Results in a nutshell

• As you might suppose
• HWVM wins when MMU ops are rare relative to
  syscalls, exceptions
• Probably awesome at running getpid
• SWVM wins the rest of the time
• Particularly good at running fork-bombs

12
So, criticism?

• Results probably true
• Can't reasonably claim obsolete hardware
• But, a straw man?
• Restates the same outcome in a dozen guises
• Ignores the main benefit of classically
  virtualisable x86
• Possible to write a small VMM
• Which unsurprisingly would be a slower