After a year of development, the launch of the new version of the free hypervisor xen 4.17, version in which the formation of updates for the Xen 4.17 branch will last until June 12, 2024 and the release of vulnerability fixes until December 12, 2025.
It is worth mentioning that companies such as Amazon, Arm, Bitdefender, Citrix, EPAM Systems and Xilinx (AMD) have contributed to the development of the new version.
Xen 4.17 Main New Features
In this new version that is presented, it is highlighted that the ability to define a static Xen configuration for ARM systems which encodes in advance all the resources needed to start the guest systems. all resourcessuch as shared memory, event notification channels, and hypervisor heap space, are pre-allocated at hypervisor startup instead of being allocated dynamically, which eliminates the possibility of failure due to lack of resources.
For embedded systems based on ARM architecture, has been implemented experimental support (tech preview) For I/O virtualization using the VirtIO protocols, virtio-mmio is used to communicate with the virtual I/O device, which has allowed us to ensure compatibility with a wide range of VirtIO devices. We can also find the compatibility implemented for the Linux frontend, with libxl/xl, the dom0less mode and the userspace backends.
Another of the changes that stands out is the improved support for dom0less mode, what allows to avoid implementing a dom0 environment when starting virtual machines at an early stage of server boot.
The ability to define CPU groups (CPUPOOL) at boot stage (through the device tree), which allows to use groups in configurations without dom0, for example, to link different types of CPU cores in ARM systems based on the big.LITTLE architecture, which combines powerful, but power-hungry cores, and less productive, but more energy-efficient cores. Additionally, dom0less provides the ability to bind the paravirtualization frontend/backend to guests, allowing you to boot guests with the necessary paravirtualized devices.
In ARM systems, memory virtualization structures (P2M, physical to machine) now are allocated from the created memory pool when a domain is created, allowing for better isolation between guests when memory-related failures occur.
In the systems x86, IOMMU pages are supported (superpage) for all types of guest systems, allowing increased performance when forwarding devices, PCI, plus added support for hosts with up to 12TB of RAM. At the boot stage, the ability to set cpuid parameters for dom0 is implemented. The VIRT_SSBD and MSR_SPEC_CTRL parameters are proposed to control hypervisor-level protection against CPU attacks on guest systems.
Of the other changes that stand out:
- Added protection against Specter-BHB vulnerability in processor microarchitecture structures for ARM systems.
- On ARM systems, the ability to run the Zephyr OS in the Dom0 root environment is provided.
The possibility of a separate hypervisor assembly (outside the tree) is provided.
Separately, the VirtIO-Grant transport is being developed, which differs from VirtIO-MMIO in a higher level of security and the ability to run controllers in a separate isolated domain for controllers.
Instead of direct memory mapping, VirtIO-Grant uses the translation of the guest's physical addresses into lease links, allowing the use of pre-agreed shared memory areas for data exchange between the guest and the VirtIO backend. , without granting the backend the right to perform memory mapping. VirtIO-Grant support is already implemented in the Linux kernel, but is not yet included in the QEMU, virtio-vhost and toolkit (libxl/xl) backends.
The Hyperlaunch initiative continues to develop to provide flexible tools for customizing the launch of virtual machines at system boot time. Currently, the first set of patches is ready, making it possible to define PV domains and transfer their images to the hypervisor on upload. you
Finally if you are interested in knowing more about it, you can consult the details in the following link.
Be the first to comment