outline for today announcements –1 st programming assignment coming soon. objective of the lecture...

Outline for Today

• Announcements– 1st programming assignment coming soon.

• Objective of the lecture– OS and Virtual Machines

Shells?

Producer/Consumer Pipes

outputinput

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 (“<“ and “>”).

• 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)

NativeDeviceDriver

GuestOS(XenLinux)

Device Manager & Control s/w

VM0

NativeDeviceDriver

GuestOS(XenLinux)

UnmodifiedUser

Software

VM1

Front-EndDevice Drivers

GuestOS(XenLinux)

UnmodifiedUser

Software

VM2

Front-EndDevice Drivers

GuestOS(XenBSD)

UnmodifiedUser

Software

VM3

Safe HW IF

Xen Virtual Machine Monitor

Back-End 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