Hardware-assisted virtualization

From Citizendium
Revision as of 15:58, 28 February 2010 by imported>Howard C. Berkowitz (New page: {{Cleanup|date=August 2008}} First implemented on the IBM System/370<ref>Fisher-Ogden, page 2</ref>, '''hardware-assisted virtualization''' is a platform virtualization approach t...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Template:Cleanup

First implemented on the IBM System/370[1], hardware-assisted virtualization is a platform virtualization approach that enables efficient full virtualization using help from hardware capabilities, primarily from the host processors. Full virtualization is used to simulate a complete hardware environment, or virtual machine, in which an unmodified guest operating system (using the same instruction set as the host machine) executes in complete isolation. Hardware-assisted virtualization was recently (2006) added to x86 processors (Intel VT or AMD-V).


Hardware-assisted virtualization is also known as accelerated virtualization; Xen calls it hardware virtual machine (HVM), Virtual Iron calls it native virtualization.

History

See also: Timeline of virtualization development

Hardware-assisted virtualization was first introduced on the IBM System/370 in 1972, for use with VM/370, the first virtual machine operating system. Virtualization was eclipsed in the late 1970s, with the advent of minicomputers that allowed for efficient timesharing, and later with the commoditization of microcomputers.

The proliferation of x86 servers rekindled interest in virtualization. The primary driver was the potential for server consolidation: virtualization allowed a single server to replace multiple underutilized dedicated servers.

However, the x86 architecture did not meet the Popek and Goldberg virtualization requirements to achieve “classical virtualization″:

  • equivalence: a program running under the VMM should exhibit a behavior essentially identical to that demonstrated when running on an equivalent machine directly;
  • resource control (also called safety): the VMM must be in complete control of the virtualized resources;
  • efficiency: a statistically dominant fraction of machine instructions must be executed without VMM intervention.

This made it difficult to implement a virtual machine monitor for this type of processor. Specific limitations included the inability to trap on some privileged instructions.

To compensate for these architectural limitations, virtualization of the x86 architecture has been accomplished through two methods: full virtualization or paravirtualization.[2] Both create the illusion of physical hardware to achieve the goal of operating system independence from the hardware but present some trade-offs in performance and complexity.

Paravirtualization has primarily been used for university research - Denali or Xen. The research projects employ this technique to run modified versions of operating systems, for which source code is readily available (such as Linux and FreeBSD). A paravirtualized virtual machine provides a special API requiring substantial OS modifications. The best known commercial implementations of paravirtualization are modified Linux kernels from XenSource and GNU/Linux distributors.

Full virtualization was implemented in first-generation x86 VMMs. It relies on binary translation to trap and virtualize the execution of certain sensitive, non-virtualizable instructions. With this approach, critical instructions are discovered (statically or dynamically at run-time) and replaced with traps into the VMM to be emulated in software. Binary translation can incur a large performance overhead in comparison to a virtual machine running on natively virtualized architectures such as the IBM System/370. VirtualBox and VMware Workstation (for 32-bit guests only), as well as Microsoft Virtual PC, are well-known commercial implementations of full virtualization.

With hardware-assisted virtualization, the VMM can efficiently virtualize the entire x86 instruction set by handling these sensitive instructions using a classic trap-and-emulate model in hardware, as opposed to software.

Intel and AMD came with distinct implementations of hardware-assisted x86 virtualization, Intel VT and AMD-V, respectively. On the Itanium architecture, hardware-assisted virtualization is known as VT-i.

Well-known implementations of hardware-assisted x86 virtualization include VMware Workstation (for 64-bit guests only), Xen 3.x (including derivatives like Virtual Iron), Linux KVM and Microsoft Hyper-V.

Pros

Hardware-assisted virtualization reduces the maintenance overhead of paravirtualization as it restricts (ideally, eliminates) the amount of changes needed in the guest operating system. It is also considerably easier to obtain better performance. A practical benefit of hardware-assisted virtualization that has been cited by VMware engineers[3] and Virtual Iron.

Cons

Hardware-assisted virtualization requires explicit support in the host CPU, which is not available on all x86/x86_64 processors.

A “pure” hardware-assisted virtualization approach, using entirely unmodified guest operating systems, involves many VM traps, and thus high CPU overheads; this limits scalability and the efficiency of server consolidation.[4] This performance hit can be mitigated by the use of paravirtualized drivers; the combination has been called “hybrid virtualization”[5].

See also

References

  1. Fisher-Ogden, page 2
  2. Chris Barclay, New approach to virtualizing x86s, Network World, 10/20/2006
  3. See http://x86vmm.blogspot.com/2005/12/graphics-and-io-virtualization.html
  4. See http://www.valinux.co.jp/documents/tech/presentlib/2007/2007xenconf/Intel.pdf
  5. Jun Nakajima and Asit K. Mallick, Hybrid-Virtualization—Enhanced Virtualization for Linux, in Proceedings of the Linux Symposium, Ottawa, June 2007, http://ols.108.redhat.com/2007/Reprints/nakajima-Reprint.pdf

Bibliography

  • John Fisher-Ogden (UCSD), Hardware Support for Efficient Virtualization, online copy