Advancing Xen on RISC-V: key updates

At Vates, we are heavily invested in the advancement of Xen and the RISC-V architecture. RISC-V, a rapidly emerging open-source hardware architecture, is gaining traction due to its flexibility, scalability and openness, which align perfectly with our ethos of fostering open development ecosystems.

Xen and the RISC-V Hypervisor Extension

As some readers may know, we’ve been working on porting Xen to RISC-V. This blog looks at why we care about RISC-V and how RISC-V satisfies what is needed from an ISA in order to support virtualization.

XCP-ng BlogBobby Eshleman

Current Xen RISC-V support status

Take a look at our current progress on our RISC-V port to the Xen Project.

XCP-ng BlogOleksii Kurochko

New Xen updates on RISC-V

Explore our latest update to learn about recent advancements and challenges in RISC-V Xen’s development, including new implementations and promising progress in this new CPU architecture.

XCP-ng BlogOleksii Kurochko

Although the upstream version of Xen for RISC-V is not yet fully operational for widespread "practical use", we’ve made significant strides, and we’re excited to share the latest updates on this project.

Xen common code for 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).

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.

For example, previously introduced generic handling macros from <xen/bug.h>, like BUG(), WARN(), and others, 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.

Additionally, we are in the process of transitioning from the early_printk() debugging tool to the more standard printk() function. While this migration isn't complete yet, it’s expected that printk() will soon replace most instances of early_printk() once Xen’s common code for RISC-V becomes fully functional. This step might bring uniformity across architectures and simplify logging and debugging processes for RISC-V code.

Introduction of architecture-specific headers

To build a fully functioning Xen environment on RISC-V, several architecture-specific header files have been introduced. Some of these headers are placeholders (stubs), designed to satisfy common code dependencies during the build process.

However, others provide essential functionality specific to RISC-V, such as:

• Fences: ensuring proper memory access ordering across CPU cores.
• Atomic compare and exchange: essential for managing concurrent data structures.
• Bit and atomic operations: key for manipulating bits and performing atomic actions across processors.
• I/O operations: to manage input/output functions critical to system performance.

Shared Functionality Through asm-generic

By incorporating the asm-generic header functionality into Xen’s build process, we’ve been able to further reduce the need for redundant architecture-specific headers. The asm-generic headers allow multiple architectures to share the same logic, minimizing the duplication of effort and maintenance overhead. This is particularly useful for operations that aren’t unique to RISC-V and can be generalized across different CPU architectures. Examples of such cases can be found here.

Refactoring Bit Operations

We have refactored the bit operations code to make it reusable across architectures, reducing duplication. The following updates were made:

• Non-atomic test functions (test_*bit()) have been moved to a more generic implementation.
• The fls() and flsl() functions, which are used to find the last set bit, have been refactored to common logic.
• The __ffs() function (find first set bit) has been implemented in a Linux-compatible header, increasing cross-compatibility.

These enhancements, many of which were led by Xen contributor Andrew Cooper, lay the groundwork for future, more advanced functionality.

CI Containers Update

In our continuous effort to streamline development processes, we’ve updated our CI (Continuous Integration) containers. These containers are now based on the Debian 11/12 distributions for RISC-V (riscv64), leading to smaller Docker images and more efficient builds. This change simplifies the testing and build processes, ensuring that we can maintain fast, reliable feedback loops during development.

• Debian 11/12-riscv64 containers: now the standard for CI testing.
• Switched to Debian for riscv64 builds: this update ensures smoother build and testing processes for RISC-V code.

What's next: ongoing and upcoming developments

While these upstream improvements have significantly advanced RISC-V support in Xen, several additional features are currently under development and will be introduced soon:

• Basic interrupt handling: this will complete support for GENERIC_BUG_FRAME, bringing essential interrupt functionality to Xen on RISC-V.
• Device tree mapping: essential for managing hardware resources.
• Page table handling: to optimize memory management.
• Fixmap setup: for managing fixed virtual addresses.
• Architecture-specific pmap functions: to handle physical memory mappings more efficiently.
• SBI RFENCE Extension: to facilitate inter-processor communication and synchronization.

Not Yet Upstreamed: Dom0less and Device Passthrough

In addition to these ongoing efforts, we are also working on several features that have not yet been upstreamed, but will be crucial for future use cases. These include:

• Dom0less Support: A lightweight setup that enables running Xen without a privileged domain (dom0), which can be beneficial for embedded and constrained environments.
• Device Passthrough: Allowing direct access to physical hardware devices, a key feature for high-performance virtualization.
• Partial AIA Support (APLIC + IMSIC): Enhancing the interrupt architecture.
• IOMMU Integration: For efficient memory isolation and mapping in virtualized environments.

These features are still in progress, but we plan to provide a more detailed overview in a separate blog post once they are closer to completion.

Stay Tuned

The pace of development for Xen on RISC-V is accelerating, and we are excited to see how this architecture will continue to evolve. As always, we are committed to contributing to open-source development and ensuring that RISC-V becomes a first-class citizen in the Xen ecosystem.

For those interested in tracking our progress in real-time, you can follow the latest changes in our repository here.