Virtual Machine Monitors CSE451 Andrew Whitaker

Hardware Virtualization Running multiple operating systems on a single physical machine Examples: VMWare, Microsoft’s VirtualPC / VirtualServer, Parallels (Macintosh), Xen

Virtual Machine Monitors Type I VMM runs on the raw hardware Type II VMM runs hosted on another OS Windows virtual machine Linux virtual machine virtual machine monitor hardware

VMM History Conceived by IBM in the late 1960’s Popularized by VM/370 (1972) Used for OS debugging, time sharing, supporting multiple OS’s Batch processing OS Time sharing OS VM/370 System 370 Machine

VMMs Today OS development and debugging Software compatibility testing Running software from another OS Or, OS version Virtual infrastructure for Internet services

Internet Services Many applications now run inside the Internet Search engines, maps, photo sharing, email, IM, game servers, etc. Goal: allow anyone to upload to a new service into the Internet Must be low-cost, secure, robust, easy to maintain, etc. Approach: use VMMs to provide a rent-a-server economy

Amazon’s Elastic Compute Cloud (EC2) Provide service developers with a set virtual machines and storage resources Scalability New machines can be created in minutes Security Virtual machines provide stronger isolation than OS processes Developer control Developers choose the OS, software, libraries, etc. Low cost Developers pay only for what they use

VMM Implementation Overview A VMM is just an operating system that exposes a (virtual) hardware interface Windows virtual machine Linux virtual machine virtual architecture Virtual machines safely shared. Even if the system has one disk, we need the appearance of N virtual disks; N TLBs; N Processors; N Ethernet devices, etc. = virtual machine monitor physical architecture hardware

Comparing the Unix and VMM APIs Storage File system (virtual) disk Networking Sockets (virtual) Ethernet Memory Virtual Memory (virtual) Physical memory Display /dev/console (virtual) Keyboard, display device

Possible Implementation Strategy: Complete machine emulation The VMM implements the complete hardware architecture in software while(true) { Instruction instr = fetch(); // emulate behavior in software instr.emulate(); } Drawback: This is really slow

Review: Protection in Traditional OS’s Hardware exposes a user/kernel boundary Operating system runs in kernel mode Processes run in user mode Processes can safely execute most instructions No need to “emulate” machine behavior But, a small set of instructions can only execute in privileged mode e.g., writing to an I/O device, disabling interrupts, etc.

Improving VMM Performance Treat guest operating systems like an application Most instructions execute natively on the CPU Privileged instructions must be trapped and emulated Virtual machines Physical hardware loads,stores, branches, ALU operations Systems lore: make the common case fast, and the uncommon case correct machine halt, I/O instructions, MMU manipulation VMM

Handling Privileged Instruction Virtual machine issues a privileged instruction (e.g., disk read) VMM determines whether the virtual machine was in “user” mode or “kernel” mode Note: the virtual mode is distinct from the physical mode (Yikes!) If “user” mode, raise a protection exception If “kernel” mode, emulate the disk read in software; then, return control to the guest OS

Tracing Through a File System Read Application Guest OS VMM read() syscall trap handler handle read syscall read from disk() trap privileged instruction If “kernel” mode: emulate virtual disk else: raise protection violation finish read syscall copy data to user buffer return from system call return from read()

Virtual Disk: Possible Implementations Static disk partitions A file in the file system Especially for type-II VMMs A special virtual disk file system A network storage abstraction e.g., Amazon’s S3 Use the layer of indirection to provide new services. For example, we could provide cryptographic storage, even if the OS/ file system do not implement this behavior

Virtualizing the User/Kernel Boundary Both the guest OS and applications run in (physical) user-mode This is necessary so that privileged instructions trap into the VMM For each virtual machine, the VMM keeps a software mode bit: During a system call, switch to “kernel” mode On system call return, switch to “user” mode Note: A faster implementation is possible on x86

(Virtual) Physical Memory Each guest OS expects its own page tables, TLB, memory-management unit, etc. Unlike the virtual disk, we can’t trap and emulate every memory reference WAY too slow Additional complication: protection bits Some memory can only be accessed in “kernel” mode

Memory Model Virtual Memory (Applications) Increasing privilege Physical Memory (Guest OS) Machine Memory (VMM) Assume a software-loaded TLB: InsertTLB(int virtualPageNumber,int physPageNumber);

Virtual Physical Memory, Implementation (Bad) Option #1: Insert the V-to-P mapping directly into the TLB; Trap each memory access to return the V-to-M memory Better Option #2: Instead of inserting a V-to-P mapping, transparently insert a V-to-M mapping This way, all future memory references will occur at hardware speed

Performance Details TLB must be flushed on a process switch and a virtual machine switch Whenever a virtual machine regains the processor, it requires numerous page faults to restore its virtual memory mappings Optimization: VMM maintains a cache of V-to-M mappings for each virtual machine On taking a page fault, the VMM can insert the appropriate TLB mapping without consulting the guest OS