Virtual Machine Monitors
Download
Report
Transcript Virtual Machine Monitors
Virtual Machine Monitors
CSE451
Andrew Whitaker
Hardware Virtualization
Running multiple operating systems on a
single physical machine
Examples:
VMWare, Microsoft’s VirtualPC / VirtualServer,
Parallels (Macintosh), Xen
Virtual Machine Monitors
Type I VMM runs on the raw hardware
Type II VMM runs hosted on another OS
Windows
Linux
virtual machine
virtual machine
virtual machine monitor
hardware
VMM History
Conceived by IBM in the late 1960’s
Popularized by VM/370 (1972)
Used for OS debugging, time sharing,
supporting multiple OS’s
Batch processing
Time sharing
OS
OS
VM/370
System 370 Machine
VMMs Today
OS development and debugging
Software compatibility testing
Running software from another OS
Or, OS version
Virtual infrastructure for Internet services
Internet Services
Many applications now run inside the Internet
Search engines, maps, photo sharing, email, IM, game
servers, etc.
Goal: allow anyone to upload to a new service
into the Internet
Must be low-cost, secure, robust, easy to maintain, etc.
Approach: use VMMs to provide a rent-a-server
economy
Amazon’s Elastic Compute Cloud
(EC2)
Provide service developers with a set virtual
machines and storage resources
Scalability
New machines can be created in minutes
Security
Virtual machines provide stronger isolation than OS
processes
Developer control
Developers choose the OS, software, libraries, etc.
Low cost
Developers pay only for what they use
VMM Implementation Overview
A VMM is just an operating system that
exposes a (virtual) hardware interface
Windows
Linux
virtual machine
virtual machine
virtual machine monitor
hardware
virtual
architecture
=
physical
architecture
Comparing the Unix and VMM APIs
UNIX
VMM
Storage
File system
(virtual) disk
Networking
Sockets
(virtual) Ethernet
Memory
Virtual Memory
(virtual) Physical
memory
Display
/dev/console
(virtual) Keyboard,
display device
Possible Implementation Strategy:
Complete machine emulation
The VMM implements the
complete hardware architecture
in software
while(true) {
Instruction instr = fetch();
// emulate behavior in software
instr.emulate();
}
Drawback: This is really slow
Review: Protection in Traditional
OS’s
Hardware exposes a user/kernel boundary
Operating system runs in kernel mode
Processes run in user mode
Processes can safely execute most instructions
No need to “emulate” machine behavior
But, a small set of instructions can only execute
in privileged mode
e.g., writing to an I/O device, disabling interrupts, etc.
Improving VMM Performance
Treat guest operating systems like an application
Most instructions execute natively on the CPU
Privileged instructions must be trapped and emulated
Virtual machines
loads,stores,
branches,
ALU operations
VMM
Physical hardware
machine halt,
I/O instructions,
MMU manipulation
Handling Privileged Instruction
Virtual machine issues a privileged instruction
(e.g., disk read)
VMM determines whether the virtual machine
was in “user” mode or “kernel” mode
Note: the virtual mode is distinct from the physical mode
(Yikes!)
If “user” mode, raise a protection exception
If “kernel” mode, emulate the disk read in
software; then, return control to the guest OS
Tracing Through a File System Read
Application
Guest OS
VMM
read() syscall
trap handler
handle read syscall
read from disk()
finish read syscall
copy data to user buffer
return from system call
return from read()
trap privileged instruction
If “kernel” mode:
emulate virtual disk
else:
raise protection violation
Virtual Disk: Possible
Implementations
Static disk partitions
A file in the file system
Especially for type-II VMMs
A special virtual disk file system
A network storage abstraction
e.g., Amazon’s S3
Virtualizing the User/Kernel Boundary
Both the guest OS and applications run in
(physical) user-mode
This is necessary so that privileged instructions trap into
the VMM
For each virtual machine, the VMM keeps a
software mode bit:
During a system call, switch to “kernel” mode
On system call return, switch to “user” mode
Note: A faster implementation is possible on x86
(Virtual) Physical Memory
Each guest OS expects its own page
tables, TLB, memory-management unit,
etc.
Unlike the virtual disk, we can’t trap and
emulate every memory reference
WAY too slow
Additional complication: protection bits
Some memory can only be accessed in “kernel”
mode
Memory Model
Virtual Memory
(Applications)
Increasing
privilege
Physical Memory
(Guest OS)
Machine Memory
(VMM)
Assume a software-loaded TLB:
InsertTLB(int virtualPageNumber,int physPageNumber);
Virtual Physical Memory,
Implementation
(Bad) Option #1: Insert the V-to-P mapping
directly into the TLB; Trap each memory
access to return the V-to-M memory
Better Option #2: Instead of inserting a Vto-P mapping, transparently insert a V-toM mapping
This way, all future memory references will
occur at hardware speed
Performance Details
TLB must be flushed on a process switch and a
virtual machine switch
Whenever a virtual machine regains the
processor, it requires numerous page faults to
restore its virtual memory mappings
Optimization: VMM maintains a cache of V-to-M
mappings for each virtual machine
On taking a page fault, the VMM can insert the
appropriate TLB mapping without consulting the guest
OS