Operating System “Structures”
Otto J. Anshus
1 Demo •POS P5 (today) •MorbOS (tomorrow)
2 “Structures” (Architectures) • Layered • OS as Resource Manager & Protector • Monolithic – HW (CPU, memory, ...) – SW (file systems, network stack, ...) • Micro kernel – Isolate users and processes from each other • OS as illusionist (a.k.a. virtual machine) • Virtual Machine – Abstractions – Easy use of abstractions • Unix: read/write data from/to sockets instead of having to • Hybrids handle TCP/IP packets in user level code
3 Layered
• Hiding information at each layer • Develop a layer at a time Level N • Examples . – THE (6 layers, semaphores, Dijkstra 1968) . – MS-DOS (4 layers) Level 2 • Pros – Separation of concerns Level 1 – Elegant (at first sight) • Cons Hardware – Protection boundary crossings – Performance
4 Layered
• Hiding information at each layer • Develop a layer at a time Level N • Examples . – THE (6 layers, semaphores, Dijkstra 1968) . – MS-DOS (4 layers) Level 2 • Pros – Separation of concerns Level 1 – Elegant (at first sight) • Cons Hardware – Protection boundary crossings – Performance Each layer can end up having to support multiple events happening (a.k.a. complications (and we don’t like complications))
4 Layered
• Hiding information at each layer • Develop a layer at a time Level N • Examples . . B – THE (6 layers, semaphores, Dijkstra 1968) . A – MS-DOS (4 layers) Level 2 D • Pros – Separation of concerns Level 1 – Elegant (at first sight) • Cons Hardware – Protection boundary crossings – Performance Each layer can end up having to support multiple events happening (a.k.a. complications (and we don’t like complications))
4 Monolithic
• All of OS is in a fat Kernel User User • Examples program program
– Classic Unix (Linux, BSD Unix, ...) return – Windows NT (hybrid) call – Mach (can be a fat kernel) – MacOS (Mach kernel)
• Pro entry – Performance – Shared kernel space Kernel (Does it all) • Cons – Stability: Faulty drivers can crash the system (>75% of a modern OS are drivers). – Flexibility: Low • (However, made flexible with loadable kernel modules (Linux)) – Security • All runs in privileged kernel mode, with direct access to kernel data structures. • Kernel allow module loading (Great for a rootkit.) 5 Microkernel • Micro-kernel has just a few abstractions and functionalities – Abstractions • Process abstraction, address space, interrupts, IPC User OS – Syscall & very few services process Services • OS Services are implemented as user level processes return • Micro-kernel gets services on behalf of users by messaging call message with the service processes passing • Old – Nucleus, Taos, Mach (as a micro kernel, drivers still in entry kernel), • Newer µ−kernel – Minix (Andy Tanenbaum, VU) – Singularity (MS Research) Mach: The mother of all microkernels, 1985-1994. Rick – EROS/CoyotOS (Johns Hopkins University) Rashid (CMU, Microsoft Research), Avie Tevanian (ex-Apple CTO), Brian Bershad (U of Washington, Google) – L4 microkernel family (originally Jochen Liedtke when at IBM/GMD/Karlsruhe) Single Server Unix (BSD4.3) MkLinux (OSF) Brinch-Hansen: “The Nucleus of a Multiprogramming IBM Workplace OS 6 System..”, 1970. Recommended readings. NeXT OS -> Mac OS X Microkernel Pros et Cons • Pros – Smaller kernel User OS • Less bugs • Easier to tune/optimize process Services • Easier to port to a new platform return – Extend or customize call – Do verification – Trust (TCB) – Fault isolation entry • Cons Interrupt handler µ−kernel – Harder to let system services share resources Dispatcher • Why?
7 Microkernel Pros et Cons • Pros – Smaller kernel User OS • Less bugs • Easier to tune/optimize process Services • Easier to port to a new platform return – Extend or customize call – Do verification – Trust (TCB) – Fault isolation entry • Cons Interrupt handler µ−kernel – Harder to let system services share resources Dispatcher • Why? – Performance • Naive case: Multiple protection boundary crossings – How many? 7 Microkernel Pros et Cons • Pros – Smaller kernel User OS • Less bugs • Easier to tune/optimize process Services • Easier to port to a new platform return – Extend or customize call – Do verification – Trust (TCB) – Fault isolation entry • Cons Interrupt handler µ−kernel – Harder to let system services share resources Dispatcher • Why? – Performance • Naive case: Multiple protection boundary crossings – How many? 7 Microkernel Pros et Cons • Pros – Smaller kernel User OS • Less bugs • Easier to tune/optimize process Services • Easier to port to a new platform return – Extend or customize call – Do verification – Trust (TCB) – Fault isolation entry • Cons Interrupt handler µ−kernel – Harder to let system services share resources Dispatcher • Why? – Performance • Naive case: Multiple protection boundary crossings – How many? 7 Microkernel Pros et Cons • Pros – Smaller kernel User OS • Less bugs • Easier to tune/optimize process Services • Easier to port to a new platform return – Extend or customize call – Do verification – Trust (TCB) – Fault isolation entry • Cons Interrupt handler µ−kernel – Harder to let system services share resources Dispatcher • Why? – Performance • Naive case: Multiple protection boundary crossings – How many? 7 Microkernel Pros et Cons • Pros – Smaller kernel User OS • Less bugs • Easier to tune/optimize process Services • Easier to port to a new platform return – Extend or customize call – Do verification – Trust (TCB) – Fault isolation entry • Cons Interrupt handler µ−kernel – Harder to let system services share resources Dispatcher • Why? – Performance • Naive case: Multiple protection boundary crossings – How many? 7 User User process process
Operating System Kernel
INTERRUPT HANDLER: Analyze interrupt; Get parameters and Start requested service Service Service int 8016 Service SCHEDULER: Select next process to resume
DISPATCHER: restore context and iret Interrupt Hardware
Interrupts from network, disk, keyboard,… User User process process Call Service(…);
int 80h
Operating System Kernel
INTERRUPT HANDLER: Analyze interrupt; Get parameters and Start requested service Service Service int 8016 Service SCHEDULER: Select next process to resume
DISPATCHER: restore context and iret Interrupt Hardware
Interrupts from network, disk, keyboard,… User User process process Call Service(…);
int 80h
Operating System Kernel
INTERRUPT HANDLER: Analyze interrupt; Get parameters and Start requested service Service Service int 8016 Service SCHEDULER: Select next process to resume
DISPATCHER: restore context and iret Interrupt Hardware
Interrupts from network, disk, keyboard,… User User process process Call Service(…);
int 80h
Operating System Kernel
INTERRUPT HANDLER: Analyze interrupt; Get parameters and Start requested service Service Service int 8016 Service SCHEDULER: Select next process to resume
DISPATCHER: restore context and iret Interrupt Hardware
Interrupts from network, disk, keyboard,… User User process process Call Service(…);
int 80h
Operating System Kernel
INTERRUPT HANDLER: Analyze interrupt; Get parameters and Start requested service Service Service int 8016 Service SCHEDULER: Select next process to resume
DISPATCHER: restore context and iret Interrupt Hardware
Interrupts from network, disk, keyboard,… User User process process Call Service(…);
int 80h
Operating System Kernel
INTERRUPT HANDLER: Analyze interrupt; Get parameters and Start requested service Service Service int 8016 Service SCHEDULER: Select next process to resume
DISPATCHER: restore context and iret Interrupt Hardware
Interrupts from network, disk, keyboard,… User User process process Call Service(…);
int 80h
Operating System Kernel
INTERRUPT HANDLER: Analyze interrupt; Get parameters and Start requested service Service let Service run || OSK continue Service int 8016 Service SCHEDULER: Select next process to resume
DISPATCHER: restore context and iret Interrupt Hardware
Interrupts from network, disk, keyboard,… User User process process Call Service(…);
int 80h
Operating System Kernel
INTERRUPT HANDLER: Analyze interrupt; Get parameters and Start requested service Service let Service run || OSK continue Service int 8016 Service SCHEDULER: Select next process to resume
DISPATCHER: restore context and iret Interrupt
Hardware ALTERNATIVELY: Sometimes later int 80h (when Service finishes) {K||service||processes} int by HW Interrupts from network, disk, keyboard,… User User process process Call Service(…);
int 80h
Operating System Kernel
INTERRUPT HANDLER: Analyze interrupt; make UL caller of Service Ready again AND write results to UL memory Get parameters and Start requested service Service let Service run || OSK continue Service int 8016 Service SCHEDULER: Select next process to resume
DISPATCHER: restore context and iret Interrupt
Hardware ALTERNATIVELY: Sometimes later int 80h (when Service finishes) {K||service||processes} int by HW Interrupts from network, disk, keyboard,… User User Service process process Service Call Service(…); Service Service int 80h
Operating System Kernel
INTERRUPT HANDLER: Analyze interrupt; make UL caller of Service Ready again AND write results to UL memory Get parameters and Start requested service Service let Service run || OSK continue Service int 8016 Service SCHEDULER: Select next process to resume
DISPATCHER: restore context and iret Interrupt
Hardware ALTERNATIVELY: Sometimes later int 80h (when Service finishes) {K||service||processes} int by HW Interrupts from network, disk, keyboard,… User User Service process process Service Call Service(…); Service Service int 80h
Operating System Kernel
INTERRUPT HANDLER: Analyze interrupt; make UL caller of Service Ready again AND write results to UL memory Get parameters and Start requested service Service let Service run || OSK continue Service int 8016 Service SCHEDULER: Select next process to resume
DISPATCHER: restore context and iret Interrupt
Hardware ALTERNATIVELY: Sometimes later int 80h (when Service finishes) {K||service||processes} int by HW Interrupts from network, disk, keyboard,… User User Service process process Service Call Service(…); Service Service int 80h
Operating System Kernel
INTERRUPT HANDLER: Analyze interrupt; make UL caller of Service Ready again AND write results to UL memory Get parameters and Start requested service Service let Service run || OSK continue Service int 8016 Service SCHEDULER: Select next process to resume
DISPATCHER: restore context and iret Interrupt
Hardware ALTERNATIVELY: Sometimes later int 80h (when Service finishes) {K||service||processes} int by HW Interrupts from network, disk, keyboard,… User User process process Service What we need to happen: Give params to service Service and get the service (its PCB) into R_Q. Call Service(…); Service Message passing Service • @IH Service Routine Thread: • @Service: int 80h send(); receive(); receive(); do service; send(); Operating System Kernel
INTERRUPT HANDLER: Analyze interrupt; make UL caller of Service Ready again AND write results to UL memory Get parameters and Start requested service Service let Service run || OSK continue Service int 8016 Service SCHEDULER: Select next process to resume
DISPATCHER: restore context and iret Interrupt
Hardware ALTERNATIVELY: Sometimes later int 80h (when Service finishes) {K||service||processes} int by HW Interrupts from network, disk, keyboard,… User User process process Service What we need to happen: Give params to service Service and get the service (its PCB) into R_Q. Call Service(…); Service Message passing Service • @IH Service Routine Thread: • @Service: int 80h send(); receive(); receive(); do service; send(); Operating System Kernel
INTERRUPT HANDLER: Analyze interrupt; make UL caller of Service Ready again AND write results to UL memory Get parameters and Start requested service Service let Service run || OSK continue Service int 8016 Service int 80 SCHEDULER: Select next process to resume 16
DISPATCHER: restore context and iret Interrupt
Hardware ALTERNATIVELY: Sometimes later int 80h (when Service finishes) {K||service||processes} int by HW Interrupts from network, disk, keyboard,… User User process process Service What we need to happen: Give params to service Service and get the service (its PCB) into R_Q. Call Service(…); Service Message passing Service • @IH Service Routine Thread: • @Service: int 80h send(); receive(); receive(); do service; send();
Operating System Kernel
INTERRUPT HANDLER: KL service also can. UL service cannot. Analyze interrupt; make UL caller of Service Ready again AND write results to UL memory Get parameters and Start requested service Service let Service run || OSK continue Service int 8016 Service int 80 SCHEDULER: Select next process to resume 16
DISPATCHER: restore context and iret Interrupt
Hardware ALTERNATIVELY: Sometimes later int 80h (when Service finishes) {K||service||processes} int by HW Interrupts from network, disk, keyboard,… User User process process Service What we need to happen: Give params to service Service and get the service (its PCB) into R_Q. Call Service(…); Service Message passing Service • @IH Service Routine Thread: • @Service: int 80h send(); receive(); receive(); do service; send();
Operating System Kernel
INTERRUPT HANDLER: KL service also can. UL service cannot. Analyze interrupt; make UL caller of Service Ready again AND write results to UL memory Get parameters and Start requested service Service let Service run || OSK continue Service int 8016 Service int 80 SCHEDULER: Select next process to resume 16
DISPATCHER: restore context and iret Interrupt
Hardware ALTERNATIVELY: Sometimes later int 80h (when Service finishes) Overhead {K||service||processes} int by HW Interrupts from network, •Crossing the border UL -> KL disk, keyboard,… •UL context -> another UL context ULP ➙ Kernel; Kernel Message Passing ➙ Services Syscall: P-to-K K-to-S: msg passing
This is what we want to achieve: interaction Application process
File System process LFS
Interrupt handler
Waiting To user level process queues etc Scheduler & Dispatcher ULP ➙ Kernel; Kernel Message Passing ➙ Services Syscall: P-to-K K-to-S: msg passing
This is what we want to achieve: interaction Application process FS process receive (kernel, parameters); File System process
Interrupt handler
Waiting To user level process queues etc Scheduler & Dispatcher ULP ➙ Kernel; Kernel Message Passing ➙ Services Syscall: P-to-K K-to-S: msg passing
This is what we As a result of this callsyscall the FS process will be removed from R_Q by Int. handler and put into a waiting_queue want to achieve: interaction Application process FS process receive (kernel, parameters); File System process
Interrupt handler
Waiting To user level process queues etc Scheduler & Dispatcher ULP ➙ Kernel; Kernel Message Passing ➙ Services Syscall: P-to-K K-to-S: msg passing
This is what we As a result of this callsyscall the FS process will be removed from R_Q by Int. handler and put into a waiting_queue want to achieve: interaction Application process FS process call rd(file_ID, param, result) syscall receive (kernel, parameters); File System process
As a result of this call the app. process will be removed from R_Q by Int. handler and put into a waiting_queue
Interrupt handler
Waiting To user level process queues etc Scheduler & Dispatcher ULP ➙ Kernel; Kernel Message Passing ➙ Services Syscall: P-to-K K-to-S: msg passing
This is what we As a result of this callsyscall the FS process will be removed from R_Q by Int. handler and put into a waiting_queue want to achieve: interaction Application process FS process call rd(file_ID, param, result) syscall receive (kernel, parameters); File System process
As a result of this call the app. process will be removed from R_Q by Int. handler and put into a waiting_queue
Interrupt handler Write to PARAMETERS
Waiting To user level process queues etc Scheduler & Dispatcher ULP ➙ Kernel; Kernel Message Passing ➙ Services Syscall: P-to-K K-to-S: msg passing
This is what we As a result of this callsyscall the FS process will be removed from R_Q by Int. handler and put into a waiting_queue want to achieve: interaction Application process FS process call rd(file_ID, param, result) syscall receive (kernel, parameters); File System process
As a result of this call the app. process will be removed from R_Q by Int. handler and put into a waiting_queue
Interrupt handler “send” to LFS Write to PARAMETERS
Waiting To user level process queues etc Scheduler & Dispatcher ULP ➙ Kernel; Kernel Message Passing ➙ Services Syscall: P-to-K K-to-S: msg passing
This is what we As a result of this callsyscall the FS process will be removed from R_Q by Int. handler and put into a waiting_queue want to achieve: interaction Application process FS process call rd(file_ID, param, result) syscall receive (kernel, parameters); File System process
As a result of this call the app. process will be removed from R_Q by Int. handler and put into a waiting_queue
Interrupt handler “send” to LFS Write to PARAMETERS
Waiting To user level process queues etc Scheduler & Dispatcher
Scheduler picks a process to be CURRENT. Eventually the FS process becomes CURRENT and does the requested service and calls SEND(). Later, after the S is finished, the ULP will be selected. ULP ➙ Kernel; Kernel Message Passing ➙ Services Syscall: P-to-K K-to-S: msg passing
This is what we As a result of this callsyscall the FS process will be removed from R_Q by Int. handler and put into a waiting_queue want to achieve: interaction Application process FS process call rd(file_ID, param, result) syscall receive (kernel, parameters); File System process
As a result of this call the app. process will be removed from R_Q by Int. handler and put into a waiting_queue
Interrupt handler “send” to LFS Write to PARAMETERS
Waiting To user level process queues etc Scheduler & Dispatcher
Scheduler picks a process to be CURRENT. Eventually the FS process becomes CURRENT and does the requested service and calls SEND(). Later, after the S is finished, the ULP will be selected. ULP ➙ Kernel; Kernel Message Passing ➙ Services Syscall: P-to-K K-to-S: msg passing
This is what we As a result of this callsyscall the FS process will be removed from R_Q by Int. handler and put into a waiting_queue want to achieve: interaction Application process FS process call rd(file_ID, param, result) syscall receive (kernel, parameters); File System process
As a result of this call the app. process will be removed from R_Q by Int. handler and put into a waiting_queue
Write to RESULT Interrupt handler “send” to LFS Write to PARAMETERS
Waiting To user level process queues etc Scheduler & Dispatcher
Scheduler picks a process to be CURRENT. Eventually the FS process becomes CURRENT and does the requested service and calls SEND(). Later, after the S is finished, the ULP will be selected. ULP ➙ Kernel; Kernel Message Passing ➙ Services Syscall: P-to-K K-to-S: msg passing
This is what we As a result of this callsyscall the FS process will be removed from R_Q by Int. handler and put into a waiting_queue want to achieve: interaction Application process FS process call rd(file_ID, param, result) syscall receive (kernel, parameters); File System process
As a result of this call the app. process will be removed from R_Q by Int. handler and put into a waiting_queue
Write to RESULT Interrupt handler “send” to LFS Write to PARAMETERS
Waiting To user level process queues etc Scheduler & Dispatcher
Scheduler picks a process to be CURRENT. Eventually the FS process becomes CURRENT and does the requested service and calls SEND(). Later, after the S is finished, the ULP will be selected. ULP ➙ Kernel; Kernel Message Passing ➙ Services Syscall: P-to-K K-to-S: msg passing
This is what we As a result of this callsyscall the FS process will be removed from R_Q by Int. handler and put into a waiting_queue want to achieve: interaction Just one at a time? Application process Could have multiple threads inside FS process to handle FS process multiple requests concurrently. call rd(file_ID, param, result) syscall receive (kernel, parameters); File System process
As a result of this call the app. process will be removed from R_Q by Int. handler and put into a waiting_queue
Write to RESULT Interrupt handler “send” to LFS Write to PARAMETERS
Waiting To user level process queues etc Scheduler & Dispatcher
Scheduler picks a process to be CURRENT. Eventually the FS process becomes CURRENT and does the requested service and calls SEND(). Later, after the S is finished, the ULP will be selected. ULP ➙ Kernel; Kernel Message Passing ➙ Services Syscall: P-to-K K-to-S: msg passing
This is what we As a result of this callsyscall the FS process will be removed from R_Q by Int. handler and put into a waiting_queue want to achieve: interaction Just one at a time? Application process Could have multiple threads inside FS process to handle FS process multiple requests concurrently. call rd(file_ID, param, result) syscall receive (kernel, parameters); File System process
As a result of this call the app. process will be removed from R_Q by Int. handler and put into a waiting_queue
Write to RESULT Interrupt handler “send” to LFS Write to PARAMETERS
Waiting To user level process queues etc Scheduler & Dispatcher
Scheduler picks a process to be CURRENT. Eventually the FS process becomes CURRENT and does the requested service and calls SEND(). Later, after the S is finished, the ULP will be selected. Alternative approaches P ⇄S?
- Interaction between kernel and service? - Interaction between application and service?
Alternative approach 1 Application process Service process: FS
receive (kernel, parameters); call rd(etc)
User level
Kernel thread Kernel level
send (FS, parameters); receive (FS, result);
10 Alternative approaches P ⇄S?
- Interaction between kernel and service? - Interaction between application and service?
Alternative approach 1 Alternative approach 2 Application process Service process: FS Application process Service process: LFS receive (kernel, parameters); call rd(etc)
send (FS, parameters); receive (FS, result);
10 Sidebar “Truths” (a.k.a. non-truths) on Micro Kernel Flexibility and Performance NO: Can be <50 cycles • A micro kernel restricts application level flexibility. • Switching overhead kernel-user mode is inherently expensive. • Switching address-spaces is costly. NO: 6-20 microsec round-trip, • IPC is expensive. 53-500 cycles/IPC one way • Micro kernel architectures lead to memory system degradation. • Kernel should be portable (on top of a small hardware-dependent layer).
The answer is: Not necessarily so
Taken from J. Liedtke, SOSP 15 paper: ” On micro kernel construction” 11 • http://en.wikipedia.org/wiki/File:OS-structure2.svg
12 Monolithic kernel vs. Micro Kernel
• Linux kernel (3.0.4., x86 architecture) • Micro Kernel based OS – Kernel: ~ 2.5 million LoC – Fiasco kernel: ~ 34,000 LoC – Drivers: ~ 5.4 million LoC – “HelloWorld” (+boot loader +root task): ~ 10,000 LoC
Generated using David A. Wheeler's ‘SLOCCount’ http://www.dwheeler.com/sloccount/ 13 Sidebar Exokernels
http://pdos.csail.mit.edu/exo/exo-slides/sld003.htm http://pdos.csail.mit.edu/exo/exo-slides/sld004.htm
14 And now for something amazing Think about this….
• Any running program is a virtual machine – A User level programs is a VM • It runs under the control of an OS as a ready or current process (a concurrent program is composed of multiple processes and threads) – An OS is a VM • But has more privileges than UL programs • Provides a VM to the UL VMs • Controls and manages some aspects of the UL VMs
15 Drawing taken (but modified) from Smith and Nairs book: Virtual Machine Architectures, Implementations, and Applications, Morgan Kaufmann Idea of Virtualization “virtual existing in essence of effect though not in actual fact” wordnetweb.princeton.edu
A virtual machine is an “efficient, isolated duplicate of a real machine.” Popek, Goldberg, 1974 16 Drawing taken (but modified) from Smith and Nairs book: Virtual Machine Architectures, Implementations, and Applications, Morgan Kaufmann Idea of Virtualization “virtual existing in essence of effect though not in actual fact” wordnetweb.princeton.edu •Variation 1 • Multiple {Apps, OS}on top of a single VM kernel (VMM - We can have multiple virtual machine monitor)
VMs concurrently on a single computer.
Mindboggling. •Variation 2 • Multiple VMs as applications on top of an OS with other applications
17 Virtual Kernel Level Mode Virtual Machine Virtual User Level Mode User Level Mode • Virtual machine monitor – provide multiple virtual “real” hardware – run different OS codes user user • Example OS1 OSn – IBM VM/370: Started in the 70’s. Check out : Syscall trapped http://www.multicians.org/thvv/ VM0 . . . VMn 360-67.html Privileged – virtual 8086 mode instructions trapped – Java VM, VMware Virtual Machine Monitor – Xen Hardware Kernel Level Mode
Exact copies of the hardware 18 Virtual Kernel Level Mode Virtual Machine Virtual User Level Mode User Level Mode • Virtual machine monitor – provide multiple virtual “real” hardware –Dorun differentyou want OS codes to know more? user user • Example OS1 OSn – IBM VM/370: Started in the 70’s. Check out : Syscall trapped VMM on bare metal http://www.multicians.org/thvv/ VM0 . . . VMn 360-67.html(Xen, VMWare ESXi) Privileged – virtual 8086 mode vs. instructions trapped Virtual Machine Monitor – Java VM,as VMwarea kernel module – Xen (KVM, VMWare Server/Workstation, VirtualBox) Hardware Kernel Level Mode
Exact copies of the hardware 18 Non-Virtualized Virtualized
Application
system call/trap
Basic drawing adapted from J.E. Smith, 2006: Virtual Machine: Supporting Changing technology and New Applications (talk, U. of Wisconsin)
Guest OS
privileged operation next instruction
Interrupt Handler
Dispatch to User Level Process
VMM Interrupt Handler
check privileges perform operation
iret
Get location of OS Border UL-KL Interrupt Handler 19 Border SW-HW Hardware Non-Virtualized Virtualized
Application
int 80 —> gets adr. of where to go system call/trap from HW Interrupt vector Basic drawing adapted from J.E. Smith, 2006: Virtual Machine: Supporting Changing technology and New Applications (talk, U. of Wisconsin)
Guest OS
privileged operation next instruction
Interrupt Handler
Dispatch to User Level Process
VMM Interrupt Handler
check privileges perform operation
iret
Get location of OS Border UL-KL Interrupt Handler 19 Border SW-HW Hardware Non-Virtualized Virtualized
Application
int 80 —> gets adr. of where to go system call/trap from HW Interrupt vector Basic drawing adapted from J.E. Smith, 2006: Virtual Machine: Supporting Changing technology and New Applications (talk, U. of Wisconsin)
Guest OS
privileged operation next instruction
Interrupt Handler
Dispatch to User Level Process
VMM Interrupt Handler
check privileges perform operation
iret
Get location of OS Border UL-KL Interrupt Handler 19 Border SW-HW Hardware Non-Virtualized Virtualized
Application
int 80 —> gets adr. of where to go system call/trap from HW Interrupt vector Basic drawing adapted from J.E. Smith, 2006: Virtual Machine: Supporting Changing technology and New Applications (talk, U. of Wisconsin)
Guest OS
privileged operation next instruction
Interrupt Handler
Dispatch to User Level Process
VMM Interrupt Handler
check privileges perform operation
iret
Get location of OS Border UL-KL Interrupt Handler 19 Border SW-HW Hardware Non-Virtualized Virtualized
Application
int 80 —> gets adr. of where to go system call/trap from HW Interrupt vector Basic drawing adapted from J.E. Smith, 2006: Virtual Machine: Supporting Changing technology and New Applications (talk, U. of Wisconsin)
Guest OS
privileged operation next instruction
Interrupt Handler
Dispatch to User Level Process
VMM Interrupt Handler
check privileges perform operation
iret
Get location of OS Border UL-KL Interrupt Handler 19 Border SW-HW Hardware Non-Virtualized Virtualized
Application
int 80 —> gets adr. of where to go system call/trap from HW Interrupt vector Basic drawing adapted from J.E. Smith, 2006: Virtual Machine: Supporting Changing technology and New Applications (talk, U. of Wisconsin)
Guest OS
privileged operation next instruction
Interrupt Handler
Dispatch to User Level Process
VMM Interrupt Handler
check privileges perform operation
iret
Get location of OS Border UL-KL Interrupt Handler 19 Border SW-HW Hardware Non-Virtualized Virtualized
Application
int 80 —> gets adr. of where to go system call/trap from HW Interrupt vector Basic drawing adapted from J.E. Smith, 2006: Virtual Machine: Supporting Changing technology and New Applications (talk, U. of Wisconsin)
Guest OS
privileged operation next instruction
Interrupt Handler
Dispatch to User Level Process
VMM Interrupt Handler
check privileges perform operation
iret
Get location of OS Border UL-KL Interrupt Handler 19 Border SW-HW Hardware Old Virtual Machine Systems
• CMSCambridge Monitor System or Conversational Monitor System. Single User Interactive OS developed in conjunction with the Virtual Machine Control Program CP-40 at IBM Cambridge Laboratories. Later adapted for CP-67 and VM/370. Late 1960s [Meyer & Seawright 1970]. • CPControl Program. A component of VM/370 for the IBM/370. CP is the kernel which implements the virtual machine. Early 1970s. • CP-40Virtual machine control program for a modified IBM 360/40. See also CMS. Mid 1960s [Goldberg 1974]. • CP-67Virtual machine control program for the IBM 360/67. Successor to CP-40. See also CMS. Late 1960s [Meyer & Seawright 1970]. • HITAC 8400 OSA Virtual machine system for the Hitac 8400 (RCA Spectra 70/45). Late 1960s [Goldberg 1974]. • IBM 360/30 OSVirtual machine for the IBM 360/30. Late 1960s [Goldberg 74].M44/44XVirtual machine system for modified IBM 7044. An early exploration of virtual machine ideas. Mid 1960s [Goldberg 1974, Belady et al 1981]. • Newcastle Recursive VMVirtual Machine system developed on a Burroughs 1700. Early 1970s [Goldberg 1974]. • PDP-10Virtual machine system for the PDP-10. Early 1970s [Goldberg 1974]. • UCLA VMVirtual machine system developed at UCLA for modified PDP-11/45 for data security studies. Early 1970s [Goldberg 1974]. • UMMPSVirtual machine system for the IBM 360/67. Early 1970s [Goldberg 1974]. • VM/370Virtual machine system for IBM 370. Successor to CP-67. See also CMS. First Release 1972 [IBMSJ 1979, Creasy 1981]. • VM/PCA version of VM/370 for the PC/370. Early 1980s [Daney & Foth 1984]. • VOSVirtual machine OS running on the Michigan Terminal System. Early 1970s [Srodowa & Bates20 1973]. 21 Virtual 8086
22 Java VM
23 Virtual Machine Hardware Support
• What is the minimal support? • 2 modes • Exception and interrupt trapping • Can virtual machine be protected without such support? • Yes, emulation instead of executing on real machine
24 Pro et Contra
Monolithic Layered VM C/S Micro kernel
•Many virtual computers with •More flexible different OS’es •Small means less •Clean, less bugs •Test of new OS while bugs+manageable •Clear division of •Performance: + production work •Clear division of labour •Distributed systems labour continues •Failure isolation of services at •All in all: flexibility Kernel Level
•Performance: ? •Flexibility: ? •More unstructured •Performance: - •Performance: - •Complexity issues: ? •Performance: ? •Less protection •Not clean, more inside OS bugs
25 Some Links
• Virtual machine • http://whatis.techtarget.com/definition/0,,sid9_gci213305,00.html • Exokernel • http://pdos.lcs.mit.edu/exo/ • THE • http://www.cs.utexas.edu/users/EWD/ewd01xx/EWD196.PDF • L4 • http://os.inf.tu-dresden.de/L4/ • VM • http://www.vm.ibm.com/
26