Difference between revisions of "Virtualization Fundamentals"

From Open-IOV
Jump to navigation Jump to search
(Added Microkernels Meet Recursive Virtual Machines)
Line 9: Line 9:
== [https://www.flux.utah.edu/download?uid=106 Microkernels Meet Recursive Virtual Machines] ==
== [https://www.flux.utah.edu/download?uid=106 Microkernels Meet Recursive Virtual Machines] ==
This paper describes a novel approach to providing mod- ular and extensible operating system functionality and en- capsulated environments based on a synthesis of micro- kernel and virtual machine concepts. We have developed a software-based virtualizable architecture called Fluke that allows recursive virtual machines (virtual machines running on other virtual machines) to be implemented ef- ficiently by a microkernel running on generic hardware. A complete virtual machine interface is provided at each level; efficiency derives from needing to implement only new functionality at each level. This infrastructure allows common OS functionality, such as process management, demand paging, fault tolerance, and debugging support, to be provided by cleanly modularized, independent, stack- able virtual machine monitors, implemented as user pro- cesses. It can also provide uncommon or unique OS fea- tures, including the above features specialized for particu- lar applications’ needs, virtual machines transparently dis- tributed cross-node, or security monitors that allow arbi- trary untrusted binaries to be executed safely. Our proto- type implementation of this model indicates that it is prac- tical to modularize operating systems this way. Some types of virtual machine layers impose almost no overhead at all, while others impose some overhead (typically 0–35%), but only on certain classes of applications.
This paper describes a novel approach to providing mod- ular and extensible operating system functionality and en- capsulated environments based on a synthesis of micro- kernel and virtual machine concepts. We have developed a software-based virtualizable architecture called Fluke that allows recursive virtual machines (virtual machines running on other virtual machines) to be implemented ef- ficiently by a microkernel running on generic hardware. A complete virtual machine interface is provided at each level; efficiency derives from needing to implement only new functionality at each level. This infrastructure allows common OS functionality, such as process management, demand paging, fault tolerance, and debugging support, to be provided by cleanly modularized, independent, stack- able virtual machine monitors, implemented as user pro- cesses. It can also provide uncommon or unique OS fea- tures, including the above features specialized for particu- lar applications’ needs, virtual machines transparently dis- tributed cross-node, or security monitors that allow arbi- trary untrusted binaries to be executed safely. Our proto- type implementation of this model indicates that it is prac- tical to modularize operating systems this way. Some types of virtual machine layers impose almost no overhead at all, while others impose some overhead (typically 0–35%), but only on certain classes of applications.
== [https://www.vmware.com/pdf/asplos235_adams.pdf A Comparison of Software and Hardware Techniques for x86 Virtualization] ==
Until recently, the x86 architecture has not permitted classical trap-and-emulate virtualization. Virtual Machine Monitors for x86, such as VMwareR Workstation and Virtual PC, have instead used binary translation of the guest kernel code. However, both Intel and AMD have now introduced architectural extensions to support classical virtualization. We compare an existing software VMM with a new VMM designed for the emerging hardware support. Surprisingly, the hardware VMM often suffers lower performance than the pure software VMM. To determine why, we study architecture-level events such as page table updates, context switches and I/O, and find their costs vastly different among native, software VMM and hardware VMM execution. We find that the hardware support fails to provide an unambiguous performance advantage for two primary reasons: first, it offers no support for MMU virtualization; second, it fails to co-exist with existing software techniques for MMU virtualization. We look ahead to emerging techniques for addressing this MMU virtualization problem in the context of hardware-assisted virtualization.

Revision as of 15:43, 7 April 2022

This following page is intended to index and summarize information related to the fundamentals of virtualization of computer systems.

Popek and Goldberg Virtualization Requirements

The Popek and Goldberg virtualization requirements are a set of conditions sufficient for a computer architecture to support system virtualization efficiently. They were introduced by Gerald J. Popek and Robert P. Goldberg in their 1974 article "Formal Requirements for Virtualizable Third Generation Architectures". Even though the requirements are derived under simplifying assumptions, they still represent a convenient way of determining whether a computer architecture supports efficient virtualization and provide guidelines for the design of virtualized computer architectures.

Goldberg Survey of Virtual Machine Research

The complete instruction-by-instruction simulation of one computer system on a different system is a well-known computing technique. It is often used for software development when a hardware base is being altered. For example, if a programmer is developing software for some new special purpose (e.g., aerospace) computer X which is under construction and as yet unavailable, he will likely begin by writing a simulator for that computer on some available general-purpose machine G. The simulator will provide a detailed simulation of the special-purpose environment X, including its processor, memory, and I/O devices. Except for possible timing dependencies, programs which run on the “simulated machine X” can later run on the “real machine X” (when it is finally built and checked out) with identical effect. The programs running on X can be arbitrary — including code to exercise simulated I/O devices, move data and instructions anywhere in simulated memory, or execute any instruction of the simulated machine. The simulator provides a layer of software filtering which protects the resources of the machine G from being misused by programs on X.

Microkernels Meet Recursive Virtual Machines

This paper describes a novel approach to providing mod- ular and extensible operating system functionality and en- capsulated environments based on a synthesis of micro- kernel and virtual machine concepts. We have developed a software-based virtualizable architecture called Fluke that allows recursive virtual machines (virtual machines running on other virtual machines) to be implemented ef- ficiently by a microkernel running on generic hardware. A complete virtual machine interface is provided at each level; efficiency derives from needing to implement only new functionality at each level. This infrastructure allows common OS functionality, such as process management, demand paging, fault tolerance, and debugging support, to be provided by cleanly modularized, independent, stack- able virtual machine monitors, implemented as user pro- cesses. It can also provide uncommon or unique OS fea- tures, including the above features specialized for particu- lar applications’ needs, virtual machines transparently dis- tributed cross-node, or security monitors that allow arbi- trary untrusted binaries to be executed safely. Our proto- type implementation of this model indicates that it is prac- tical to modularize operating systems this way. Some types of virtual machine layers impose almost no overhead at all, while others impose some overhead (typically 0–35%), but only on certain classes of applications.

A Comparison of Software and Hardware Techniques for x86 Virtualization

Until recently, the x86 architecture has not permitted classical trap-and-emulate virtualization. Virtual Machine Monitors for x86, such as VMwareR Workstation and Virtual PC, have instead used binary translation of the guest kernel code. However, both Intel and AMD have now introduced architectural extensions to support classical virtualization. We compare an existing software VMM with a new VMM designed for the emerging hardware support. Surprisingly, the hardware VMM often suffers lower performance than the pure software VMM. To determine why, we study architecture-level events such as page table updates, context switches and I/O, and find their costs vastly different among native, software VMM and hardware VMM execution. We find that the hardware support fails to provide an unambiguous performance advantage for two primary reasons: first, it offers no support for MMU virtualization; second, it fails to co-exist with existing software techniques for MMU virtualization. We look ahead to emerging techniques for addressing this MMU virtualization problem in the context of hardware-assisted virtualization.