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