A critical assault upon “A Comparison of Software and Hardware Techniques for x86 Virtualization”

A critical assault upon “A Comparison of Software and Hardware Techniques for x86 Virtualization” Chris Smowton

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

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)

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

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

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

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

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

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

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

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

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

A critical assault upon “A Comparison of Software and Hardware Techniques for x86 Virtualization”