1,798
edits
Changes
→Hypervisor Virtualization
Clearly, with the hypervisor occupying ring 0 of the CPU, the kernels for any guest operating systems running on the system must run in unprivileged CPU rings. Unfortunately, most operating system kernels are written to run in ring 0 for the simple reason that they need to perform tasks that are only available in that ring such as the ability to execute privileged CPU instructions and directly manipulate memory. A number of different solutions to this problem has been devised in recent years, each of which is described below:
- '''Paravirtualization''' - Under paravirtualization the guest kernels are modified specifically to run on the hypervisor. This typically involves replacing any privileged operations that will only run in ring 0 of the CPU with calls to the hypervisor (known as ''hypercalls''). The hypervisor in turn performs the task on behalf of the guest kernel. This typically limits support to open source operating systems such as Linux and proprietary operating systems where the owners have agreed to make the necessary modifications to target a specific hypervisor. These issues not withstanding, the ability of the guest kernel to communicate directly with the hypervisor results in greater performance levels than other virtualization approaches.
- '''Full Virtualization''' - Full virtualization provides support for unmodified guest operating systems. The term ''unmodified'' refers to operating system kernels which have not be altered to run on a hypervisor and therefore still execute privileged operations as though running in ring 0 of the CPU. In this scenario, the hypervisor provides CPU emulation to handle and modify privileged and protected CPU operations made by unmodified guest operating system kernels. Unfortunately this emulation process requires both time and system resources to operate resulting in inferior performance levels when compared to those provided by paravirtualization.
