Xen Project 4.15 Feature List: Difference between revisions
IanJackson (talk | contribs) (edits) |
IanJackson (talk | contribs) (fix) |
||
| (11 intermediate revisions by the same user not shown) | |||
| Line 9: | Line 9: | ||
Xenstored and oxenstored both now support LiveUpdate (tech preview), allowing security fixes to be applied without having to restart the entire host |
Xenstored and oxenstored both now support LiveUpdate (tech preview), allowing security fixes to be applied without having to restart the entire host |
||
“PV Shim” mode, for supporting legacy PV guests on HVM-only systems, continues to be improved; its size was reduced by further factoring out HVM-specific code. This will also help reduce the size and security of any PV-only build of the hypervisor. |
“PV Shim” mode, for supporting legacy PV guests on HVM-only systems, continues to be improved; its size was reduced by further factoring out HVM-specific code. This will also help reduce the size and improve the security of any PV-only build of the hypervisor. |
||
Unified boot images: It is now possible to create an image bundling together files needed for Xen to boot into a single EFI binary; making it now possible to boot a functional Xen system directly from the EFI boot manager, rather than having to go through grub multiboot. Files that can be bundled include a hypervisor, dom0 kernel, dom0 initrd, Xen KConfig, XSM configuration, and a device tree. |
Unified boot images: It is now possible to create an image bundling together files needed for Xen to boot into a single EFI binary; making it now possible to boot a functional Xen system directly from the EFI boot manager, rather than having to go through grub multiboot. Files that can be bundled include a hypervisor, dom0 kernel, dom0 initrd, Xen KConfig, XSM configuration, and a device tree. |
||
Developed IOREQ server in Xen on Arm for further enablement of VirtIO protocols as a generic and standardized solution for I/O virtualization |
Developed IOREQ server in Xen on Arm for further enablement of VirtIO protocols as a generic and standardized solution for I/O virtualization. Ability to expose a VirtIO block device to a Xen on Arm guest. Reference implementation of VirtIO block device for Xen on Arm (collaboration between Arm, EPAM and Linaro’s project STRATOS) |
||
= Features and improvements = |
|||
Reference implementation of VirtIO block device for Xen on Arm – collaboration between Arm, EPAM and Linaro’s project STRATOS |
|||
Arm Renesas IPMMU-VMSA support upgraded to Supported, not security supported (was Tech Preview in 4.14). |
|||
| ⚫ | |||
Switched x86 MSR accesses to deny by default policy. |
|||
| ⚫ | |||
Named PCI devices for xl/libxl and improved documentation for xl PCI configuration format. |
|||
| ⚫ | |||
Support for zstd-compressed dom0 (x86) and domU kernels. |
|||
| ⚫ | |||
Reduce ACPI verbosity by default. |
|||
| ⚫ | Progress on tracking and maintaining safety requirements including collaboration with Zephyr to build a Doxygen-based infrastructure that generates safety requirements documents from in-code comments and text files. It will allow proper maintenance of safety-related artifacts next to the code under git and keep them up to date easily in the community. |
||
Add <code>ucode=allow-same</code> option to test late microcode loading path. |
|||
== VirtIO drivers for Xen == |
|||
Library improvements from NetBSD ports upstreamed. |
|||
Progress includes: |
|||
x86: Allow domains to use AVX-VNNI instructions. |
|||
| ⚫ | |||
Added <code>XEN_SCRIPT_DIR</code> configuration option to specify location for Xen scripts, rather than hard-coding <code>/etc/xen/scripts</code>. |
|||
Ability to expose a VirtIO block device to a Xen on Arm guest. |
|||
xennet: Documented a way for the backend (or toolstack) to specify MTU to the frontend. |
|||
Some additional affordances in various xl subcommands. |
|||
Added workarounds for the following ARM errata: Cortex A53 #843419, Cortex A55 #1530923, Cortex A72 #853709, Cortex A73 #858921, Cortex A76 #1286807, Neoverse-N1 #1165522. |
|||
On detecting a host crash, some debug key handlers can automatically triggered to aid in debugging. |
|||
Increase the maximum number of guests which can share a single IRQ from 7 to 16, and make this configurable with <code>irq-max-guests</code>. |
|||
== CI loop (gitlab CI) == |
|||
Add Alpine Linux, Ubuntu Focal targets; drop CentOS 6. |
|||
Add qemu-based dom0 / domU test for ARM. |
|||
Add dom0less aarch64 smoke test. |
|||
= Ongoing activities = |
|||
The Xen community has several interesting initiatives, where work is ongoing and is expected to bear fruit in forthcoming releases. Some of the highlights: |
|||
| ⚫ | |||
| ⚫ | |||
| ⚫ | |||
| ⚫ | |||
| ⚫ | Progress on tracking and maintaining safety requirements including collaboration with Zephyr to build a Doxygen-based infrastructure that generates safety requirements documents from in-code comments and text files. It will allow proper maintenance of safety-related artifacts next to the code under git and keep them up to date easily in the community. |
||
| ⚫ | |||
“Hyperlaunch” |
|||
The Xen community, led by sub-project XCP.ng, is working on a RISC-V Port for Xen. Progress includes: |
|||
| ⚫ | “Dom0less” pioneered the ability to configure Xen to launch a static set of virtual machines by Xen at boot time. But configuration for these domains was very basic, and focused on embedded use cases. “Hyperlaunch” is a new initiative that intends to make this configuration far more flexible by generalizing it and introducing a “boot domain” (domB). Draft design documents have been posted, and a working group has been formed to form a plan to complete iron out the details. |
||
| ⚫ | |||
| ⚫ | |||
| ⚫ | |||
RISC-V, an open standard instruction set architecture (ISA) based on established reduced instruction set computer (RISC) principles, is a free and open ISA enabling hardware designers to design simpler chips with a royalty-free ISA. The Xen community, led by sub-project XCP.ng, is working on a RISC-V Port for Xen. |
|||
== Other interesting progress == |
|||
Progress includes: |
|||
| ⚫ | |||
| ⚫ | |||
| ⚫ | “Hyperlaunch”: “Dom0less” pioneered the ability to configure Xen to launch a static set of virtual machines by Xen at boot time. But configuration for these domains was very basic, and focused on embedded use cases. “Hyperlaunch” is a new initiative that intends to make this configuration far more flexible by generalizing it and introducing a “boot domain” (domB). Draft design documents for Hyperlaunch have been posted, and a working group has been formed to form a plan to complete iron out the details. |
||
| ⚫ | |||
Latest revision as of 16:05, 8 April 2021
Notable Features
Arm now allows running device models in dom0 (tech preview), allowing arbitrary devices to be emulated for Arm guests. Arm also now has SMMUv3 support (also tech preview), which will improve security and reliability of device pass-through on Arm systems.
Xen can now export Intel Processor Trace (IPT) data from guests to tools in dom0, enabling tools like https://github.com/intel/kernel-fuzzer-for-xen-project or https://github.com/CERT-Polska/drakvuf-sandbox
Xen now supports Viridian enlightenments for guests with more than 64 vcpus.
Xenstored and oxenstored both now support LiveUpdate (tech preview), allowing security fixes to be applied without having to restart the entire host
“PV Shim” mode, for supporting legacy PV guests on HVM-only systems, continues to be improved; its size was reduced by further factoring out HVM-specific code. This will also help reduce the size and improve the security of any PV-only build of the hypervisor.
Unified boot images: It is now possible to create an image bundling together files needed for Xen to boot into a single EFI binary; making it now possible to boot a functional Xen system directly from the EFI boot manager, rather than having to go through grub multiboot. Files that can be bundled include a hypervisor, dom0 kernel, dom0 initrd, Xen KConfig, XSM configuration, and a device tree.
Developed IOREQ server in Xen on Arm for further enablement of VirtIO protocols as a generic and standardized solution for I/O virtualization. Ability to expose a VirtIO block device to a Xen on Arm guest. Reference implementation of VirtIO block device for Xen on Arm (collaboration between Arm, EPAM and Linaro’s project STRATOS)
Features and improvements
Arm Renesas IPMMU-VMSA support upgraded to Supported, not security supported (was Tech Preview in 4.14).
Switched x86 MSR accesses to deny by default policy.
Named PCI devices for xl/libxl and improved documentation for xl PCI configuration format.
Support for zstd-compressed dom0 (x86) and domU kernels.
Reduce ACPI verbosity by default.
Add ucode=allow-same option to test late microcode loading path.
Library improvements from NetBSD ports upstreamed.
x86: Allow domains to use AVX-VNNI instructions.
Added XEN_SCRIPT_DIR configuration option to specify location for Xen scripts, rather than hard-coding /etc/xen/scripts.
xennet: Documented a way for the backend (or toolstack) to specify MTU to the frontend.
Some additional affordances in various xl subcommands.
Added workarounds for the following ARM errata: Cortex A53 #843419, Cortex A55 #1530923, Cortex A72 #853709, Cortex A73 #858921, Cortex A76 #1286807, Neoverse-N1 #1165522.
On detecting a host crash, some debug key handlers can automatically triggered to aid in debugging.
Increase the maximum number of guests which can share a single IRQ from 7 to 16, and make this configurable with irq-max-guests.
CI loop (gitlab CI)
Add Alpine Linux, Ubuntu Focal targets; drop CentOS 6.
Add qemu-based dom0 / domU test for ARM.
Add dom0less aarch64 smoke test.
Ongoing activities
The Xen community has several interesting initiatives, where work is ongoing and is expected to bear fruit in forthcoming releases. Some of the highlights:
Functional Safety
Progress continues to be made within the Functional Safety SIG. Specifications are becoming more concrete and the group is working with other communities to establish standards. Additionally, Xen is working with other projects to converge best practices across communities.
Updates include:
Progress on MISRA-C rules tailored for Xen in collaboration with Zephyr. MISRA-C is a set of coding guidelines for the language for safety. The SIG now has a shortlist of MISRA-C rules that apply to our project and we are currently evaluating static analyzers for each of them.
Progress on tracking and maintaining safety requirements including collaboration with Zephyr to build a Doxygen-based infrastructure that generates safety requirements documents from in-code comments and text files. It will allow proper maintenance of safety-related artifacts next to the code under git and keep them up to date easily in the community.
RISC-V Port
The Xen community, led by sub-project XCP.ng, is working on a RISC-V Port for Xen. Progress includes:
Development of host and guest virtual memory management code, one of the key components necessary for supporting guest virtualization
Development of the internal architecture-specific code to conform to Xen common APIs
Other interesting progress
Moving towards enabling PCIe virtualization support for Xen on Arm (collaboration between Xilinx, Arm, EPAM and Renesas)
“Hyperlaunch”: “Dom0less” pioneered the ability to configure Xen to launch a static set of virtual machines by Xen at boot time. But configuration for these domains was very basic, and focused on embedded use cases. “Hyperlaunch” is a new initiative that intends to make this configuration far more flexible by generalizing it and introducing a “boot domain” (domB). Draft design documents for Hyperlaunch have been posted, and a working group has been formed to form a plan to complete iron out the details.
