1 / 41

Virtualization

Virtualization. C/S in a Single Computer. Computer System Engineering (2013 Spring). OS Structure. Operating System. Goals Multiplexing Protection Cooperation Portable Performance Technologies Virtualization, e.g., memory and CPU Abstraction, e.g., FS, bounded buffer, window.

neil-alston
Download Presentation

Virtualization

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Virtualization C/S in a Single Computer Computer System Engineering (2013 Spring)

  2. OS Structure

  3. Operating System • Goals • Multiplexing • Protection • Cooperation • Portable • Performance • Technologies • Virtualization, e.g., memory and CPU • Abstraction, e.g., FS, bounded buffer, window

  4. Virtualization • Widely used term involving a layer of indirection top of some abstraction

  5. Virtualization: Multiplexing • Examples: • Thread: 1 CPU looks like N CPUs • Virtual Memory: 1 memory looks like N memories • Virtual Circuit: 1 channel looks like N channels • Virtual Machine: 1 machine looks line N machines

  6. Virtualization: Aggregation • Examples: • RAID disks: N disks look like one disk • Channel Bounding: N channels look like one • Compute side: GPUs? ModuleA VirtualizationLayer ModuleA ModuleB ModB ModB ModB

  7. Virtualization: Emulation • Examples: • RAM Disk: Make a RAM memory act like a very fast disk • Apple’s Rosetta Technology: Make a x86 CPU look like a Power PC CPU; btransby Intel • Virtual Machines: VMware, Xen, KVM, Qemu, etc.

  8. C/S using Virtual Computers • Enforce Modularity: Pros • Each program has its own virtual computer • Module isolation • Error containment • Programmer can think each one independently • Enforce Modularity: Cons • A power failure knocks out all virtual computers • Hacker exploits bugs in virtualization layer • Only one of several defense lines • All of these are caused by one reason: sharing

  9. Major Abstractions • Memory • Virtual memory address space • OS gives modules their own memory name space • Communication • Bounded buffer virtual link • OS gives modules an inter-module communication channel for passing messages • Interpreter • Thread • OS gives modules a slice of a CPU

  10. Virtual Memory

  11. Memory Modularity Enforcement • No enforcement in physical memory • Any module can overwrite any other • All modules share the same address space (naming context) • Bad things happen Physicalmemorynamespace 0x9000 0x7000 0x4000 0x3000 0x0000 OS gcc disk image access emacs

  12. Virtual Memory Address Spaces • Each module gets its own names • Addresses running from 0 to maximum address • Can’t even name memory of other modules or OS • Error handling • Handles all types of Operating System memory smash errors 2n 0 2n 0 ModuleB ModuleA OperatingSystem Module

  13. Virtualizing Memory • Virtual addresses • Virtual address spaces • Virtual memory manager

  14. Using Segment

  15. Using Page Map

  16. Virtual Address Spaces • Provides each application with the illusion • Each app has a complete address space to itself • The virtual memory manager • Gives each virtual address space its own page map • Interfaces • id ←CREATE_ADDRESS_SPACE () • block ← ALLOCATE_BLOCK () • MAP (id, block, page_number, permission) • UNMAP (id, page_number) • FREE_BLOCK (block) • DELETE_ADDRESS_SPACE (id)

  17. Kernel VS. User Mode

  18. Kernel Mode • How to protect page tables? • Add one bit to the processor to indicate the mode • change the value of domain registers only in kernel mode • generate an illegal instruction exception otherwise • change the mode bit only in kernel mode • Other Isolation • Special instructions: e.g., change CR3 • I/O channels

  19. Kernel and Address Spaces • Each address space include a mapping of the kernel into its address space • Only the user-mode bit must be changed when mode switches • The kernel sets the permissions for kernel pages to KERNEL-ONLY • Kernel has its own separate address space • Inaccessible to user-level threads • Extend the SVC instruction to switch the page map address register

  20. Mode Switching • Mode switch • The machine starts in K • K->U: using iret • U->K: • Hardware • Clock interrupt, Network/Disk interrupt • Software • Exception, System call

  21. UNIX Abstractions • Why not using libraries?

  22. Library Stubs for System Calls • Use read( fd, buf, size) as an example: int read( int fd, char * buf, int size) { move fd, buf, size to R1, R2, R3 move READ to R0 int $0x80 move result to Rresult } User stack User memory Registers Kernel stack Registers Linux: 80 NT: 2E Kernel memory

  23. System Call Entry Point • Assume passing parameters in registers EntryPoint: switch to kernel stack save context check R0 call the real code pointed by R0 restore context switch to user stack iret (change to user mode and return) User stack User memory Registers Kernel stack Registers Kernel memory

  24. Mode Switching • Kernel Stack • Each process has a kernel stack • It is accessible only to the kernel but is part of the process image • Save task’s registers (e.g., user’s ESP) & function parameters and return-addresses • Kernel Stack is Small • In Linux, less than 8K (2 pages) • The stack is empty each time iret to user

  25. Kernel Stack in Linux • Linux uses part of a task’s kernel-stack to store that task’s thread_info. Why? 2157 union thread_union { 2158 structthread_infothread_info; 2159 unsigned long stack[THREAD_SIZE/sizeof(long)]; 2160 }; Room here for stack to expand as needed Kernel-mode stack 8K Thread info

  26. Mode Switching • Page Table • Each process has a page table which maps both its memory image and the kernel memory image • When switching mode from user to kernel, process switches to its kernel stack but doesn’t change the page table • Only One Kernel • Sharing page tables of kernel for all processes

  27. Call from Kernel to User void foo(intsigno) {printf(“You wanna kill me?\n”); return;} intmain() {signal(SIGINT, foo); while (1) { printf(“I’m still alive\n”); sleep (1) } } • UNIX Signal • Register signal handler • Kernel checks signalbefore iret • Kernel calls handlerif a signal is pending • How?

  28. Types of OS Structure

  29. Monolithic Kernel • The kernel must be a trusted intermediary for the memory manager hardware, • Many designers also make the kernel the trusted intermediary for all other shared devices • The clock, display, disk • Modules that manage these devices must be part of the kernel program • The window manager, network manager , file manager • Monolithic kernel • Most of the operating system runs in kernel mode

  30. Monolithic Kernel • Pros • Relatively few crossings • Shared kernel address space • Performance • Cons • Flexibility • Stability • Experimentation

  31. Microkernel • We would like to keep the kernel small • Reduce the number of bugs • Restrict errors in the module which generates the error • The file manager module error may overwrite kernel data structures unrelated to the file system • Causing unrelated parts of the kernel to fail

  32. Microkernel • System modules run in user mode in their own domain • Microkernel itself implements a minimal set of abstractions • Domains to contain modules • threads to run programs • virtual communication links

  33. Microkernel • Pros • Easier to develop services • Fault isolation • Customization • Smaller kernel => easier to optimize • Cons • Lots of boundary crossings • Really poor performance

  34. Microkernel VS. Monolithic Kernel • Few microkernel OS • Most widely-used operating systems have a mostly monolithic kernel. • the GNU/Linux operating system • the file and the network service run in kernel mode • the X Window System runs in user mode.

  35. Microkernel VS. Monolithic Kernel • A critical service doesn’t matter much if it fails • Either in user mode or in kernel mode • The system is unusable. • Some services are shared among many modules • easier to implement these services as part of the kernel program, which is already shared among all modules • The performance of some services is critical • the overhead of SEND and RECEIVE supervisor calls may be too large

  36. Microkernel VS. monolithic kernel • Monolithic systems can enjoy the ease of debugging of microkernel systems • good kernel debugging tools • It may be difficult to reorganize existing kernel programs • There is little incentive to change a kernel program that already works • If the system works and most of the errors have been eradicated • the debugging advantage of microkernel begins to evaporate • the cost of SEND and RECEIVE supervisor calls begins to dominate.

  37. Microkernel VS. monolithic kernel • How to choose • a working system and a better designed, but new system • don’t switch over to the new system unless it is much better • The overhead of switching • learning the new design • re-engineering the old system to use the new design • rediscovering undocumented assumptions • discovering unrealized assumptions

  38. Microkernel VS. monolithic kernel • The uncertainty of the gain of switching • The claims about the better design are speculative • There is little experimental evidence that • microkernel-based systems are more robust than existing monolithic kernels

  39. Exo-kernel

More Related