The effort to bring the Xen hypervisor to the RISC-V instruction set architecture has advanced – a little – but big jobs that would make both projects a contender for more workloads are still on developers’ to-do lists.
The Register offers that assertion after a Monday post from Vates – the org that gave the world the Xen fork XCP-NG and has taken a leading role in bringing the open source hypervisor to the permissively-licensed world of RISC-V.
“One of the most notable advancements has been the integration of several patch series into Xen’s staging branch (which is already a great success by itself, knowing the code quality level in Xen),” the post opens, adding that “These patches primarily focus on leveraging Xen’s common codebase to reduce redundant architecture-specific code. This move streamlines development and helps to future-proof the codebase for multi-architecture compatibility.”
The post offers some examples of that effort, leading with implementation of “previously introduced generic handling macros from BUG(), WARN(), and others, [which] can now be used with minimal additional code.”
“The primary task is defining BUG_INSN, which enables the proper handling of these macros and related sections in the linker file (lds.S). This simplification reduces the need for complex, architecture-specific implementations,” the post adds.
Worthy foundational stuff, then.
“To build a fully functioning Xen environment on RISC-V, several architecture-specific header files have been introduced,” the post adds. Some of those headers are placeholders needed to satisfy common code dependencies during the build process. Others add code that’s needed to make Xen work on RISC-V, namely:
Some other features are already in development – among them interrupt handling, device tree mapping to help the hypervisor manage hardware, page table handling to manage memory, and extensions to handle inter-processor comms.
The post states these features are “will be introduced soon,” but also reveals that some important items remain on developers’ to-do lists. Among those are device passthrough that would allow Xen-on-Risc-V to access physical devices, and efficient memory isolation.
Both are necessary to make the combination of Xen and RISC-V a contender for the kind of machines and workloads that enjoy the isolation and security afforded by virtual machines – servers, edge devices, and automotive kit – but there’s no timeframe on their arrival.
Vates did offer an optimistic view of this project’s future by writing “The pace of development for Xen on RISC-V is accelerating.” ®
