In Xen 4.4 hypervisor and Linux 3.14 kernel, hardware paravirtualization mode will be available
Transfer. Original on the Xen Blog .
From a translator: At the moment, the stable version of the Xen hypervisor supports two virtualization modes. In paravirtual mode (PV), the equipment is not emulated, and the guest OS must be specially modified in order to work in such an environment. Starting with version 3.0, the Linux kernel supports launching in paravirtual mode without recompiling with third-party patches. The advantage of PV mode is that it does not require hardware-assisted virtualization on the part of the CPU, nor does it use up resources (sometimes very significant) for emulating hardware on the PCI bus.
Hardware Virtualization (HVM) mode has been introduced in Xen since version 3.0 of the hypervisor and requires hardware support. In this mode, QEMU is used to emulate virtual devices, which is very slow even with paravirtual drivers. However, over time, hardware virtualization support in equipment has become so widespread that it is used even in laptop CPUs. Therefore, the developers had the desire to use fast switching of the execution context between the hypervisor and the guest OS and in paravirtual mode, using the capabilities of the equipment. So a new mode appeared - hardware paravirtualization, which will be available in Xen, starting with version 4.4.
Linux 3.14 kernel will support a new mode developed by Mukesh Rathor
from Oracle Corporation. The hardware paravirtualization (PVH) mode allows the guest OS to use the platform's hardware capabilities, but does not require hardware emulation using QEMU. This is an impressive step in the evolution of the paravirtual regime.
The history and subtleties of implementing the PVH mode are described in detail in The Paravirtualization Spectrum, Part 2: From poles to a spectrum .
In short, now the guest OS in Xen can work in hardware virtualization (HVM) or paravirtualization (PV) mode. In PV mode, the guest OS kernel allows the hypervisor to program memory page tables, segments, etc. If the processor supports EPT / NPT extensions, then the cost of managing memory in HVM mode (when the guest OS controls the memory) is much less than when the hypervisor in PV mode does it. So, in the new mode, the hypervisor does not manage memory and system calls inside the guest OS - all this happens inside the container of the virtual machine.
This “hybrid” paravirtualization mode is called “hardware paravirtualization” (PVH).
The advantages of this approach are a reduction in the amount of code, better performance when making system calls (there is no context switching between the guest OS and the hypervisor), fewer delays in performing various operations, in a word - a faster response of the guest OS.
The code that implements PVH mode will be available in Xen starting from version 4.4 (the 3rd release candidate for this version has already been released). If we compare the new mode with the paravirtualization mode, but there are practically no differences, except that the guest OS starts in HVM mode (but without PCI devices) and works much faster. We are still working on the intricacies of ABI in the new mode, so ABI is still unstable.
This means that in the next version of Xen, it may not even work with the current version of Linux ABI (or maybe it will). The new regime is highly experimental and unstable. We intend to bring it to the level of practical application, and by all means strive for this goal.
It will help us a lot if users try to use the new mode, so that we can track errors and problems that we could not imagine at the development stage.
How to use hardware paravirtualization?
- Download the latest version of Xen and build it. Details can be found at wiki.xen.org/wiki/Compiling_Xen_From_Source and wiki.xen.org/wiki/Xen_4.4_RC3_test_instructions
- Download the latest version of the Linux kernel. Details at wiki.xenproject.org/wiki/Mainline_Linux_Kernel_Configs#Configuring_the_Kernel
cd $ HOME
git clone git: //git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
- Build the kernel with the CONFIG_XEN_PVH = y option
- Configuration based on the kernel settings of your distribution
cp / boot / config-`uname -r `$ HOME / linux / .config
then select Processor type and features -> Linux guest support -> Support for running as a PVH guest ( NEW)
- If you prefer to edit the .config file, then you should indicate in it:
CONFIG_HYPERVISOR_GUEST = y
CONFIG_PARAVIRT = y
CONFIG_PARAVIRT_GUEST = y
CONFIG_PARAVIRT_SPINLOCKS = y
CONFIG_XEN = y
CONFIG_XEN_PVH = y
and network devices, etc. You must also enable console devices and so on, etc.
- Configuration based on the kernel settings of your distribution
- Compile and install the
make modules_install && install kernel.
You should also create a boot image (initrd), copy it and the kernel to the / boot directory and configure the bootloader.
- Start the guest OS with the pvh = 1 parameter, for example:
extra = "console = hvc0 debug kgdboc = hvc0 nokgdbroundup initcall_debug debug"
kernel = "/ boot / vmlinuz-3.13 +"
ramdisk = "/ boot / initramfs-3.13 + .cpio.gz "
memory = 1024
vcpus = 4
name =" pvh "
vif = ['mac = 00: 0F: 4B: 00: 00: 68']
vfb = ['vnc = 1, vnclisten = 0.0.0.0, vncunused = 1']
disk = ['phy: / dev / sdb1, xvda, w']
pvh = 1
on_reboot = "preserve"
on_crash = "preserve"
on_poweroff = "preserve
- Use the xl utility, the xm utility does not support the new mode.
The guest OS will boot as paravirtual, but the xen-detect utility will show that it is running in hardware virtualization mode.
The following features have not been tested:
- Virtual machine migration
- 32-bit OS in guest mode (don't even try them in PVH mode)
- Forwarding PCI devices
- Work in hypervisor mode (dom0) - patches for this have not yet been accepted into the main Xen code branch. If you want to try, you can use the branch from Mukesh Razor:
cd $ HOME / xen
git pull git: //oss.oracle.com/git/mrathor/xen.git dom0pvh-v7
In this case, you should pass dom0pvh = to Xen when loading 1 . Guest OSs in this mode are not yet supported.
The following functions do not work:
- Filtering the output of a processor identification command (CPUID). Now the result of the command is passed to the guest unchanged.
- AMD hardware virtualization
- Launch 32-bit guest OS
If you find an error, please send us the following information by e-mail firstname.lastname@example.org:
- xl dmesg
- xl list
- xenctx -s $ HOME / linux / System.map -f -a -C [domain id]
- Guest OS Console Output
- Everything else that you find important
Please save your kernel images (vmlinuz). We may need them in the future, but are too large to send them via e-mail.