The modification of the source code of an operating system in order to run as a guest operating system in a specific virtual machine environment. Calls to the hardware from the guest OS are replaced with calls to the virtual machine monitor (VMM). For example, several operating systems, such as Linux, OpenBSD, FreeBSD and OpenSolaris, have been paravirtualized for the Xen virtual machine monitor.
Paravirtualization Vs. Emulation
The guest OS can run as is without modification if the VMM emulates the hardware. In this case, the calls from the guest OS drivers to the hardware are intercepted and managed by the VMM, which redirects them to the real drivers. In addition, calls from the guest OS to the virtual memory page tables are intercepted and managed by the VMM. Emulation enables any guest OS to run intact, but emulation is slower than if the guest OS were paravirtualized.
Paravirtualization may be an option. If support for virtual machines is present in the CPU hardware, the guest OS may not need modification. For example, prior to the virtualization circuits built into x86 CPUs, the Xen VMM required the guest OS to be modified. If Xen runs in later Intel VT or AMD-V CPUs, a guest OS can run as is. See virtual machine monitor, virtual machine, hardware virtualization and Xen.
Just like running in a non-virtualized computer, a non-paravirtualized guest OS communicates with the hardware as usual. The VMM presents a "device model" to the guest OS, which emulates the hardware. In these illustrations and the one following, the emphasis is on the device drivers. Paravirtualization also refers to modifying the calls to the virtual memory tables.
In a paravirtualized OS, the drivers are replaced with calls to the VMM interface. This example shows one VMM model. For more VMM architectures, see
|
