An Overview of Virtual Machine Architectures by J.E. Smith and Ravi Nair presented by Sebastian Burckhardt University of Pennsylvania CIS 700 – Virtualization Seminar Friday, September 17, 2004

-2- About me I am a 2 nd year PhD student I was born and raised in Switzerland My academic advisor is Rajeev Alur Research Interests: –Hardware Verification Model checking Refinement and Abstraction Compositional Verification –Architecture –Formal methods

-3- Contributions of the paper Systematic taxonomy of VMs –demarcate what to include –classify into types, name each type Introduce a diagram language –comprehensive: can draw all VM types –precise: can distinguish all VM types Discuss each type –purpose –implementation issues –examples

-4- Organization of the paper 1.1Motivations for using VMs 1.2System Layers, Interfaces, and VM classes 1.3Process VMs 1.4System VMs 1.5Virtualization 1.6Taxonomy summary

-5- Standard System Layers Benefits –decoupled design tasks –software reuse across varying hardware configurations and generations Starting point for all virtual machines in this paper

-6- Disadvantages and Limitations ? Suboptimal performance across interfaces SW still depends on ISA and OS interfaces OS still depends on ISA Get locked into interface

-7- VMs for Flexibility Software perspective: want ability to run on all machines –reach more customers –move code between networked computers Hardware perspective: want ability to run all programs –server consolidation –legacy applications –cross-platform software development

-8- VMs for Performance Optimize just in time –The more you know, the more you can optimize Isolate faults and security risks –Many server images more stable than single server Increase utilization of resources –adjust allocations dynamically –reduce fragmentation

-9- Examples

-10- VM Puzzles show position of VM with respect to the standard system layers show kind of interface used between components show replication

-11- Taxonomy Overview 1.Interface at the top 1.ABI (application binary interface) 2.ISA (instruction set architecture) 2.same/different ISA at top and bottom

-12- ISA and ABI Instruction Set Architecture separates hardware from rest Application Binary Interface separates processes from rest

-13- Process level VMs provide ABI to application System VMs provide ISA to OS and applications Process vs. System VMs

-14- Process VMs (1) Multiprogramming –same ISA, same OS –replicates ABI so that each process thinks it has its own machine –standard in “modern” OS –can argue whether to call this a VM Note: replication can go both ways –multiprocessor appears as single environment –clusters, grid computing

-15- Process VMs (2) “Emulation” and “Dynamic Binary Translation” –OS is same, ISA is different –better known as “interpretation” and “compilation” Dynamic Optimizers –same OS and ISA –performance is purpose

-16- Process VMs (3) High-level VMs –Use synthetic ISA P-code (somewhat anachronistic) Java bytecode –Maximal platform independence what about OS calls? –High performance penalty? what about just-in-time compilation?

-17- Process VMs (4) This combination is left out by taxonomy: –OS is different, ISA is same –for example, run Windows x86 applications in a Linux x86 environment (e.g. WINE) –Don’t know specific term for this VM type ??

-18- System VMs (1) Classic System VMs –VMM (Virtual Machine Monitor) provides replication and resource management –possible benefits: flexibility, utilization, isolation –similar to what an OS does for processes –sits on hardware –(super)privileged mode

-19- System VMs (2) Hosted System VMs –Like classic system VM, but operates within process space –Can play tricks to overcome limitations Common to Classic/Hosted System VM: try to do as much as you can natively more difficult for hosted VMs than for classic VMs underlying ISA can make big difference

-20- System VMs (3) Whole System VMs –ISA is different –no ‘native’ execution possible. Complete emulation/translation required. –Usually done as a hosted VM

-21- System VMs (4) Co-Designed VMs –use synthetic custom ISA at bottom –goal: reconcile diverging requirements between ISA and microarchitecture –no ‘native’ execution possible –Emulation/translation can be joint effort by hardware and software can be made completely transparent

-22- General implementation issues for virtual machines How to design/verify implementation –need to map features of guest to features of host know how to materialize state (e.g. on interrupts) –compare this to architecture/microarchitecture –describe typical issues for each VM type

-23- Analogy: Architecture vs. Microarchitecture (1) Map architected state to implementation state No one-to-one relation: many implementation states per architecture state map direction is wrong?

-24- Analogy: Architecture vs. Microarchitecture (2) When designing the microarchitecture, we map features of the ISA into features of the microarchitecture When verifying the implementation, we –map implementation states to architecture state –map implementation steps to (zero or more) architecture steps –diagram must commute

-25- How to implement a VM Map guest features to host features

-26- Implementation issues: Process VMs

-27- Implementation issues: System VMs

-28- Finally: VMs on top of VMs

-29- Discussion questions Is this taxonomy good? –too broad or too narrow? –too simple or too complicated? What VM types are most relevant? Would a proliferation of VMs change –ABI’s? –ISA’s? –OS’s?

THE END -

-31-