Operating System Support for Virtual Machines

1
Operating System Support for Virtual Machines

• Coauthored by Samuel T. King, George W. Dunlap
  and Peter M. Chen
• In Proceedings of the 2003 USENIX Technical
  Conference

Presented by Ken C.K. Lee (email
cklee_at_cse.psu.edu) Jan 23, 2006
2
Outline

• Introduction
• Review of Virtual Machines
• UMLinux an evaluated Type II VMMs
• Host OS Support for Type II VMMs
• Performance Results
• Conclusions

3
Introduction

• About Virtual Machine Monitor (VMM)
• A layer of software emulating hardware of a
  complete computer system.
• Provide an abstraction virtual machine (VM).
• Could provide a VM identical to underlying
  hardware platform running VMM or totally
  different hardware platform.
• Uses of VMMs
• To create illusion of multiple machines on a
  single physical machines.
• To provide software environment for OS debugging.
• To provide means of isolation that untrusted
  applications run separately.

4
Introduction

• Two types of VMMs
• Type I
• Type II

5
Virtual Machines

• The classification of VMMs can be based on
  whether the VM created by a VMM emulates the same
  underlying hardware.
• VMs emulating the underlying hardware
  (homogeneous)
• Some performance problems due to enumeration
  overheads, additional complexity in term of
  frequent task switches and memory mapping.
• VMs emulating different hardware (heterogeneous)
• Various degree of compatibility
• Denali supports only some instructions.
• Microkernel provides high-level services that are
  not provided by hardware.
• Java VM is completely hardware independent.

6
Virtual Machines

• Another classification based on Type I/II VMMs
• This paper focuses on homogeneous Type II VMMs
• Pros
• Run as a process that system developers/administra
  tors can have an easier control on it.
• As a debugging platform
• Cons
• Undesirable performance due to lack of
  sufficiently powerful interfaces provided by
  underlying operating systems.
• Thats work to be presented in this paper.

7
UMLinux

• What is UMLinux?
• UMLinux is a Type II VMM , a case Type II VMM
  studied in this paper
• It runs upon Linux and the guest operating
  systems and guest applications run as a single
  process.
• Note The interfaces provided by UMLinux is
  similar but not identical to underlying hardware,
  so modifications on both guest OS and VMM are
  needed.
• It makes use of functionality supplied by
  underlying OS, e.g.
• process as CPU,
• Host memory mapping and protection as virtual MMU
• Memory files as file systems etc.
• files and devices as virtual devices,
• TUN/TAP devices as virtual network,
• host signal as virtual interrupts,

8
UMLinux

• UMLinux system structure
• A VMM process and a guest-machine process
• VMM process
• Redirects operating signal and system calls
• Restricts the set of system calls allowed by
  guest OS
• VMM uses ptrace to mediate access between guest
  machine process and host OS.

ptrace is a system call to observe and control
another process, and examine and change its core
image and registers. It is primarily used to
implement breakpoint debugging and system call
tracing.
9
UMLinux

• UMLinux operations
• Example

System call intercepted by VMM process via ptrace
guest SIGUSR1 handler calls mmap to access guest
kernel data intercepted by VMM process
10
Host OS support for Type II VMMs

• Three bottlenecks in running a Type II VMM
• Inordinate number of context switches between
  processes.
• A large number of memory protection operations.
• A large number of memory mapping operations.
• This paper proposed possible modifications to VMM
  and in general, the modifications involves only a
  few number of lines of code.

11
Host OS support for Type II VMMs

• Dealing with extra host context (process)
  switches
• Causes
• Using ptrace between VMM and host OS to intercept
  all requests.
• Solution
• Moving VMM processs functionality into host
  kernel.

12
Host OS support for Type II VMMs

• Dealing with a large number of memory protection
  operations
• Causes
• When the guest machine process switches between
  guest kernel mode to guest user mode, the access
  mode of guest kernels portion address space must
  be changed appropriately.
• The access mode alternation is invoked by making
  host system calls mmap, munmap and mprotect
  that incur significant overhead.

Memory map of UMLinux
13
Host OS support for Type II VMMs

• Dealing with a large number of memory protection
  operations (Contd)
• 2 Solutions
• Solution 1 By adjusting the bound on the user
  code and data segments rather than granting
  entire address space.
• Drawbacks
• Limited use of actual and available memory
  address space.

14
Host OS support for Type II VMMs

• Dealing with a large number of memory protection
  operations (Contd)
• 2 Solutions
• Solution 2 By using the page tables
  supervisor-only bit to distinguish between guest
  kernel mode and guest user mode.

15
Host OS support for Type II VMMs

• Dealing with a large number of memory mapping
  operations
• Causes
• Switching of multiple guest applications.
• Changing the current memory mapping between guest
  virtual pages and the page in virtual machines
  physical memory file.
• System calls mmap and munmap are invoked.
• Solutions
• UMLinux defers the system call til it is needed
  but it does not reduce mmap and munmap calls.
• Modification of OS (i.e. switchguest) to support
  multiple several address space definitions.
• The system call switchguest is pretty fast since
  it need to change the pointer rather than
  manipulating the actual memory.

16
Performance Results

• Objectives
• Measuring the 3 proposals for identified
  bottlenecks.
• Experiment setup
• Performance metrics
• A null system call
• Switching between two concurrent guest
  application processes (64KB each)
• (Time of) Transferring 10MB of data using TCP
  across 100Mb/s Ethernet switch.
• Three benchmarks
• POV-Ray
• Kernel-build
• SPECweb99
• AMD Athlon 1800 CPU, 256MB Memory and Linux
  kernel 2.4.18 ported to UMLinux.

17
Performance Results

• Results
• The effect are cumulated among all proposed
  schemes.

Significant improvement by reducing context
switches
Standalone must be the best
18
Performance Results

• Results (Contd)

Significant improvement by reducing context
switches
19
Performance Results

• Results

CPU intensive tasks
20
Performance Results

• Results (Contd)

• Conclusion from the result
• The improvement made according
• to the proposal is shown
• effective.

21
Summary

• Three performance bottlenecks of Type II VMM
  (i.e., UMLinux) are identified, namely,
• A number of context switches between host
  processes
• A number of memory protection operations
• A number of memory operations
• Corresponding to these bottlenecks, improvements
  are made in terms of structural change of VMM and
  exploring alternatives to some expensive system
  calls.
• Performance results prove the claims of the
  proposal.