An Overview of Virtual Machine Architectures

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

2. About me • I am a 2nd 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.1 Motivations for using VMs • 1.2 System Layers, Interfaces, and VM classes • 1.3 Process VMs • 1.4 System VMs • 1.5 Virtualization • 1.6 Taxonomy summary

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

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

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. TaxonomyOverview • Interface at the top • ABI (application binary interface) • ISA (instruction set architecture) • 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 vs. System VMs • Process level VMs provide ABI to application • System VMs provide ISA to OS and applications

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 issuesfor 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 architectedstate 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?

30. - THE END -