Xen Project 4.17 Feature List
This release has seen the increase in hardware support for both x86 and Arm, together with the addition of other improvements and features:
- MISRA-C integration: The project has officially adopted four directives and 24 rules, added MISRA-C checker build integration, and defined how to document deviations. A number of MISRA-C violations have been fixed.
- Static configuration options for ARM: In many embedded environments, we know ahead of time exactly what resources all guests will need at boot time. In constrained resource environments, allocation on use increases the possibility that the allocation will fail at runtime. With static configuration, resources are allocated statically when the hypervisor boots, removing the possibility of runtime failure. Resources which can be statically configured as of 4.17 include event channels, shared memory, and hypervisor heap.
- ARM: Add “tech preview” implementation for VirtIO. Xen now includes full support for VirtIO on embedded systems, on ARM, for the virtio-mmio transport, allowing a wide range of VirtIO devices to be supported. This includes front-end support in Linux, toolstack (libxl/xl) and dom0less support, and a userspace backend. Currently, the following stand-alone backends are available and have been tested: virtio-disk, virtio-net, i2c, and gpio.
- dom0less / Hyperlaunch: cpupools can be specified at boot using device tree. This allows the use of cpupools in dom0less / Hyperlaunch -style configurations; in particular, it makes it possible to assign different types of CPUs of an ARM big.LITTLE system to different cpupools at boot time.
- dom0less / Hyperlaunch: PV frontend / backend connections can now be specified between guests, allowing statically booted guests with PV devices
- On ARM, p2m structures are now allocated out of a pool of memory set aside at domain creation; this provides better isolation between guests against memory resource failures
- ARM: Mitigations against Spectre-BHB
- x86: IOMMU superpage support for all guest types; improving performance of PCI pass-through
- x86: Security support hosts with up to 12 TiB of RAM
- x86: Can now set cpuid parameters for dom0 at boot time
- x86: mwait-idle support: Added SPR and ADL
- x86: Improved speculative mitigation support, including VIRT_SSBD and MSR_SPEC_CTRL features to help guests know what speculative mitigations they don't need to be done (due to mitigations on the hypervisor side), and to control what kind of speculative mitigations the hypervisor performs on their behalf
- Out-of-tree builds for the hypervisor now supported
- ARM: Since addition of Zephyr RTOS guests support (Xen 4.15, Zephyr 3.1.0), work has been done on making it possible to run Zephyr in dom0 improving boot time, stability and paving the way for future safety certification for Xen-based systems
The Xen community has several interesting initiatives, where work is ongoing and is expected to bear fruit in forthcoming releases. Some of the highlights:
VirtIO-Grant is VirtIO drivers using grant operations. In contrast to VirtIO-MMIO, which does direct map, virtio-grant is safer and also supports driver domains. VirtIO-Grant support has been implemented and upstreamed in Linux at the transport level. There are patches to enable it in QEMU backends and in virtio-vhost, but these have not yet been upstreamed, nor is there toolstack support (libxl / xl) yet. Both x86 and ARM will be included in the next few releases.
Hyperlaunch The vision for Hyperlaunch is to enable complete, flexible configuration of a system of running VMs at boot time, suitable for “measured launch.” The first batch of functionality has been implemented, and patches sent to the list; this enables multiple PV domains to be specified, with their images handed to the hypervisor at boot. Everything necessary for these domains to come up, including the Xenstore entries required for PV devices to function, is implemented. Once the patch is upstreamed, we will be adding support for PVH devices and HVM devices for a pure “static configuration” mode (where no new domains can be created after boot), along with support for a “domB” builder domain, capable of setting up arbitrary domain configurations in a fashion suitable for measured boot.