Virtualization

1

Virtualization

Computer System Engineering (2013 Spring)

C/S in a Single Computer

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?

Module A

Module B

Mod B Mod B Mod B

Module A

Virtualization Layer

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; btrans by 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

OS

gcc

disk image access

emacs

0x9000

0x7000

0x4000

0x3000

0x0000

Physical memory name space

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

Operating SystemModule

Mod

ule A

Mod

ule B

2n

0

2n

0

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

}

Userstack

Registers

Usermemory

Kernelstack

Registers

Kernelmemory

Linux: 80NT: 2E

23

System Call Entry Point

• Assume passing parameters in registersEntryPoint:

switch to kernel stacksave contextcheck R0

call the real code pointed by R0

restore contextswitch to user stackiret (change to user mode and return)

Userstack

Registers

Usermemory

Kernelstack

Registers

Kernelmemory

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

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 struct thread_info thread_info;2159 unsigned long stack[THREAD_SIZE/sizeof(long)];2160 };

Room here for stack to expand as needed 8K

Thread info

Kernel-mode stack

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

• UNIX Signal– Register signal handler– Kernel checks signal

before iret– Kernel calls handler

if a signal is pending• How?

void foo(int signo) { printf(“You wanna kill me?\n”); return;}

int main() { signal(SIGINT, foo); while (1) { printf(“I’m still alive\n”); sleep (1) }}

28

29

30

TYPES OF OS STRUCTURE

31

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

32

Monolithic Kernel

• Pros– Relatively few crossings– Shared kernel address space– Performance

• Cons– Flexibility– Stability– Experimentation

33

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

34

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

35

Microkernel

• Pros– Easier to develop services– Fault isolation– Customization– Smaller kernel => easier to optimize

• Cons– Lots of boundary crossings– Really poor performance

36

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.

37

Microkernel VS. Monolithic Kernel

1. A critical service doesn’t matter much if it fails– Either in user mode or in kernel mode– The system is unusable.

2. 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

3. The performance of some services is critical– the overhead of SEND and RECEIVE supervisor calls may

be too large

38

Microkernel VS. monolithic kernel

4. Monolithic systems can enjoy the ease of debugging of microkernel systems

– good kernel debugging tools

5. 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.

39


• 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

40


• 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

41

Exo-kernel

Documents

Virtualization