Outline for Today Announcements –1 st programming assignment coming soon. Objective of the lecture –OS and Virtual Machines

Shells?

Producer/Consumer Pipes output input char inbuffer[1024]; char outbuffer[1024]; while (inbytes != 0) { inbytes = read(stdin, inbuffer, 1024); outbytes = process data from inbuffer to outbuffer; write(stdout, outbuffer, outbytes); } Pipes support a simple form of parallelism with built-in flow control. e.g.: sort <grades | grep Dan | mail justin

Shell = Command Line Interpreter Not GUI Application-level program (not part of OS) Loops –Prompting for input –Reads and parses input on command line –Invokes program specified with arguments supplied –Waits (or not – “&”) for completion Allows hooking up of multiple programs via pipes (“|”) and redirection of stdin and stdout (“ ”). Reads shell scripts.

Introduction to Virtual Machine Monitors

Traditional Multiprogrammed OS Multiple applications running with the abstraction of dedicated machine provided by OS Pass through of non- privileged instructions ISA – instruction set architecture ABI – application binary interface HW OS Application(s) ISA ABI Syscalls instr

Traditional Multiprogrammed OS HW OS Application(s) Multiple applications running with the abstraction of dedicated machine provided by OS Pass through of non- privileged instructions ISA – instruction set architecture ABI – application binary interface ISA ABI Syscalls instr

© James Smith, U.Wisc

Virtualization Layer © James Smith, U.Wisc

Variations on the Theme © James Smith, U.Wisc

Virtual Machines History: invented by IBM in 1960’s Fully protected and isolated copy of the physical machine providing the abstraction of a dedicated machine Layer: Virtual Machine Monitor (VMM) Replicating machine for multiple OSs Security Isolation © James Smith, U.Wisc

Virtual Machine Monitor © J. Sugarman, USENIX01

Issues Hardware must be fully virtualizable – all sensitive (privileged) instructions must trap to VMM –X86 is not fully virtualizable In traditional model, all devices need drivers in VMM –PCs have lots of possible devices – leverage the host OS for its drivers => hosted model

VMware Hosted Model © J. Sugarman, USENIX01

Hosting Implications World switch – heavier weight than normal context switch VMM runs with full privileges (e.g., kernel mode) I/O operations involve –Interception by VMM –Switch to host world via Vmdriver –Issuing I/O operation to host OS via Vmapp Interrupts handled by host OS –VMM yields control to host OS –Reasserts interrupts to Guest OS Host OS does scheduling and can also pageout memory of a virtual machine

VMware Hosted Model

Xen 2.0 Features Secure isolation between VMs Resource control and QoS Only guest kernel needs to be ported –All user-level apps and libraries run unmodified –Linux 2.4/2.6, NetBSD, FreeBSD, Plan9 Execution performance is close to native Supports the same hardware as Linux x86 Live Relocation of VMs between Xen nodes

Xen 2.0 Architecture Event Channel Virtual MMUVirtual CPU Control IF Hardware (SMP, MMU, physical memory, Ethernet, SCSI/IDE) Native Device Driver GuestOS (XenLinux) Device Manager & Control s/w VM0 Native Device Driver GuestOS (XenLinux) Unmodified User Software VM1 Front-End Device Drivers GuestOS (XenLinux) Unmodified User Software VM2 Front-End Device Drivers GuestOS (XenBSD) Unmodified User Software VM3 Safe HW IF Xen Virtual Machine Monitor Back-End

Para-Virtualization in Xen Arch xen_x86 : like x86, but Xen hypercalls required for privileged operations –Avoids binary rewriting –Minimize number of privilege transitions into Xen –Modifications relatively simple and self-contained Modify kernel to understand virtualised env. –Wall-clock time vs. virtual processor time Xen provides both types of alarm timer –Expose real resource availability Enables OS to optimise behaviour

x86 CPU virtualization Xen runs in ring 0 (most privileged) Ring 1/2 for guest OS, 3 for user-space –GPF if guest attempts to use privileged instr Xen lives in top 64MB of linear addr space –Segmentation used to protect Xen as switching page tables too slow on standard x86 Hypercalls jump to Xen in ring 0 Guest OS may install ‘fast trap’ handler –Direct user-space to guest OS system calls MMU virtualisation: shadow vs. direct-mode

Para-Virtualizing the MMU Guest OSes allocate and manage own PTs –Hypercall to change PT base Xen must validate PT updates before use –Allows incremental updates, avoids revalidation Validation rules applied to each PTE: 1. Guest may only map pages it owns* 2. Pagetable pages may only be mapped RO Xen traps PTE updates and emulates, or ‘unhooks’ PTE page for bulk updates

I/O Architecture Xen IO-Spaces delegate guest OSes protected access to specified h/w devices –Virtual PCI configuration space –Virtual interrupts Devices are virtualised and exported to other VMs via Device Channels –Safe asynchronous shared memory transport –‘Backend’ drivers export to ‘frontend’ drivers –Net: use normal bridging, routing, iptables –Block: export any blk dev e.g. sda4,loop0,vg3