Running openEuler RISC-V 25.09 on QEMU's RISC-V Server Platform Reference (rvsp-ref)

Source information

Source: RISC-V Developer Community
Author / ID: zevorn
Original: https://ruyisdk.cn/t/topic/1836
Original publication date: 2025-11-01

Summary

This article explains how to run openEuler RISC-V 25.09 on QEMU’s RISC-V Server Platform Reference, covering the RVA23S64 Profile, the RVSP-REF specification, progress on the QEMU machine model, and boot-time validation.

It is suitable for archiving under topics such as the QEMU RISC-V server platform, openEuler RISC-V, software-stack left-shift validation, and server reference platform adaptation.

Archive note

This is an index for a published off-site article; the full text has been imported below.

Body

openEuler RISC-V 25.09 (the community innovation release) already supports the RVA23S64 Profile, so it is well prepared for the RISC-V Server Platform Reference Spec (hereafter RVSP-REF).

Since there is currently no mature RISC-V server hardware platform that supports the full RVA23S64 Profile, we first tried building a Machine in QEMU that conforms to the RVSP-REF specification to help openEuler with software-stack left-shift development.

This article introduces the RISC-V server reference platform specification, briefly reviews the current state of QEMU RVSP-REF support, and finally explains how to boot openEuler 25.09 on the QEMU rvsp-ref Machine.

Introduction to the RISC-V server reference platform specification

RVSP-REF Spec 1.0 overview

Servers are different from the computers we use every day: they need to run stably for years and have much higher requirements for reliability, security, and performance (for example, servers in a data center cannot just crash at will, and they must also defend against hackers stealing data). Therefore, the RVSP-REF Spec defines a standardized set of hardware capabilities and interfaces so that portable system software such as operating systems and hypervisors can rely on them and achieve single binary image compatibility. This specification applies to general-purpose server systems (such as web servers and database servers) and emphasizes server-class requirements such as high reliability (RAS), security, performance, and quality of service (QoS).

The RVSP-REF Spec 1.0 was finalized in March 2025. In May of the same year, QEMU upstream updated the rvsp-ref board patch (PATCH v3), adding support for RVA23 and an IOMMU device.

A complete RISC-V server platform must include at least four parts:

Complete SoC hardware support: provides hardware interfaces such as CPU cores that meet RVA23S64, timers, advanced interrupt controllers, and PCIe root ports.
Standardized platform firmware: based on the UEFI and ACPI standards, providing boot and runtime services.
Rich management interfaces: supported by a baseboard management controller (BMC) for in-band and out-of-band management (such as MCTP, PLDM, IPMI, and Redfish).
Multiple security models: support for secure boot, debug authorization, confidential computing, and more.

Hardware module specification overview

Let’s look at some hardware module specifications that are closely related to the RISC-V architecture:

1. Clock and timer

The time counter (time CSR) must increment at a frequency of at least 100 MHz, with nanosecond units.
Timekeeping must remain continuous across low-power states of CPU cores (except for system-level sleep states).

For performance, the specification strongly recommends support for the Sstc extension, which introduces the stimecmp and vstimecmp registers to provide an efficient timer-interrupt mechanism for supervisors and virtual machines. It is a key feature for improving system performance, especially in virtualized environments.

2. Interrupt controller

The RISC-V Advanced Interrupt Architecture (AIA) must be supported.
External interrupts must be delivered through message-signaled interrupts (MSI).
IMSIC must support S-mode interrupt files and at least five VS-mode interrupt files (for virtualization).
If the SoC uses wired interrupts, they must be translated into MSI through APLIC.

It is worth noting that RISC-V AIA (Advanced Interrupt Architecture), compared with the traditional PLIC (Platform-Level Interrupt Controller), brings significant improvements in interrupt handling, performance, and virtualization support.

By introducing message-signaled interrupts (MSI), enhanced priority management, and native virtualization support, AIA moves away from the centralized, static interrupt-management model of PLIC and toward a distributed, message-based, deeply virtualization-aware modern architecture, providing a more modern and efficient solution for high-performance computing and server scenarios.

Therefore, RVSP-REF Spec 1.0 makes AIA mandatory, which is crucial for bringing RISC-V to data centers, high-performance computing, and latency-sensitive applications.

3. Input/output memory management unit (IOMMU)

All DMA devices (including PCIe and non-PCIe devices) must be managed by an IOMMU.
The RISC-V IOMMU specification must be supported, including address translation, PASID (20-bit width), ATS (Address Translation Service), and more.
Hardware performance monitoring (HPM) and error-injection features are recommended.
DMA must be disabled by default after reset to improve security.

4. PCIe subsystem

The root complex must comply with the PCIe 6.0 standard.
The ECAM configuration space must support uncached, strongly ordered accesses and ensure write-completion semantics.
The memory-mapped space must support 32-bit and 64-bit BARs and define error-handling rules for accesses (such as returning all-1 data).
ACS (Access Control Services), AER (Advanced Error Reporting), DPC (Downstream Port Containment), and other reliability features must be supported.
Optional support for PTM (Precision Time Measurement) and SR-IOV virtualization.

5. Reliability, availability, and serviceability (RAS)

ECC memory, data poisoning, and regular memory scrubbing are recommended.
RISC-V RERI (Error Record Interface) should be supported to provide persistent error logging (retained across resets).
The handling strategies for correctable errors (CE), non-fatal errors (UED), and fatal errors (UEC) must be distinguished.

It is also worth adding that RISC-V RERI (RAS Error Record Register Interface) is an important reliability, availability, and serviceability specification in the RISC-V architecture. It provides hardware interfaces for standardized error reporting and logging. In high-end applications such as data center servers, RAS features are essential.

6. Quality of service (QoS)

The SoC is required to provide resource-management mechanisms (such as cache and memory-bandwidth allocation) to reduce performance interference between applications.

7. Performance monitoring

CPU cores and the IOMMU should support hardware performance counters (at least 40 bits wide) for profiling and optimization.

8. Security

Isolate device DMA access through the IOMMU.
Support T2GPA mode (to prevent devices from abusing ATS).
Optionally integrate trusted I/O protocols such as SPDM and TDISP.

QEMU RVSP-REF progress

The current components included in the QEMU rvsp-ref Machine are as follows:

Based on the riscv virt machine type
A new memory map as close to the virt machine as possible
A new virt CPU type rvsp-ref-cpu for server-platform compliance
AIA
PCIe AHCI
PCIe NIC
No virtio device
No fw_cfg device
No ACPI table provided
Only minimal device-tree nodes

PS: The server platform specification requires BRS-I (see FIRM_010). BRS-I requires ACPI, and even some specific ACPI tables such as PPTT (see Chapter 6 of the BRS specification). However, I think the right approach here is to generate a device tree (DT) and then let edk2 generate ACPI tables from that device tree.

QEMU already supports RVA23S64, but the server specification still lacks some pieces, such as sdext. I previously shared this specification on the forum: Discussing the implementation of The RISC-V Debug Specification (I have already discussed this with upstream, and we will fill in this extension and contribute it to QEMU upstream later).

Booting openEuler on the QEMU rvsp-ref Machine

Download QEMU

The rvsp-ref patch is still outside mainline at the moment (because the sdext extension is missing), so I added some necessary components and bug fixes based on riscv-to-apply.next. You can download the source here:

git clone -b riscv-server-platform git@github.com:zevorn/qemu.git

The commit history at the time of writing is as follows:

commit 07b4e4467a94e8e538b272e5a3135d16cc98ab03 (HEAD -> riscv-server-platform, origin/riscv-server-platform)
Author: Chao Liu <chao.liu.riscv@isrc.iscas.ac.cn>
Date:   Sat Nov 1 19:04:41 2025 +0800

    hw/riscv: update rvsp-ref default cpu type to cpu-max
    
    temp patch for support openEuler 25.09
    
    Signed-off-by: Chao Liu <chao.liu.riscv@isrc.iscas.ac.cn>

Then build it with:

./configure --target-list=riscv64-softmmu && make -j$(nproc)

Verify that the build succeeded:

./build/qemu-system-riscv64 -M ?
Supported machines are:
amd-microblaze-v-generic AMD Microblaze-V generic platform
microchip-icicle-kit Microchip PolarFire SoC Icicle Kit
none                 empty machine
rvsp-ref             RISC-V Server SoC Reference board # This is the one we need
shakti_c             RISC-V Board compatible with Shakti SDK
sifive_e             RISC-V Board compatible with SiFive E SDK
sifive_u             RISC-V Board compatible with SiFive U SDK
spike                RISC-V Spike board (default)
virt                 RISC-V VirtIO board
xiangshan-kunminghu  RISC-V Board compatible with the Xiangshan Kunminghu FPGA prototype platform

Update the image

Here we take OpenEuler 25.09 as an example. You can refer to Booting openEuler-24.03-LTS-SP2 with qemu - openEuler - RISC-V Developer Community and start from virt; we need to change a few things to support the rvsp-ref Machine.

The main change is to edit grub.cfg:

1vim /boot/efi/EFI/openEuler/grub.cfg

Find this section:

        linux   /vmlinuz-6.6.0-102.0.0.5.oe2509.riscv64 root=UUID=c6dd218d-fc09--4066-bc5d-b20a8eb9da7a ro
...

Change ro to rw (we will optimize this later so that the openEuler image does not need to be modified directly).

Update the boot script

Create a new boot script with the following command:

 1#!/usr/bin/env bash
 2
 3# The script is created for starting a riscv64 qemu virtual machine with specific parameters.
 4
 5RESTORE=$(echo -en '\001\033[0m\002')
 6YELLOW=$(echo -en '\001\033[00;33m\002')
 7
 8## Configuration
 9vcpu=8
10memory=8
11drive="$(ls *.qcow2)"
12fw1="RISCV_VIRT_CODE.fd"
13fw2="RISCV_VIRT_VARS.fd"
14ssh_port=12055
15
16cmd="/home/zevorn/qemu/build/qemu-system-riscv64 \
17  -nographic -machine rvsp-ref,pflash0=pflash0,pflash1=pflash1 \
18  -smp "$vcpu" -m "$memory"G \
19  -blockdev node-name=pflash0,driver=file,read-only=on,filename="$fw1" \
20  -blockdev node-name=pflash1,driver=file,filename="$fw2" \
21  -object rng-random,filename=/dev/urandom,id=rng0 \
22   -drive file=$drive,format=qcow2,id=virtio-drive,if=none \
23   -device virtio-blk-pci,drive=virtio-drive,id=virtio-blk-0"
24
25echo ${YELLOW}:: Starting VM...${RESTORE}
26echo ${YELLOW}:: Using following configuration${RESTORE}
27echo ""
28echo ${YELLOW}vCPU Cores: "$vcpu"${RESTORE}
29echo ${YELLOW}Memory: "$memory"G${RESTORE}
30echo ${YELLOW}Disk: "$drive"${RESTORE}
31echo ${YELLOW}SSH Port: "$ssh_port"${RESTORE}
32echo ""
33echo ${YELLOW}:: NOTE: Make sure ONLY ONE .qcow2 file is${RESTORE}
34echo ${YELLOW}in the current directory${RESTORE}
35echo ""
36echo ${YELLOW}:: Tip: Try setting DNS manually if QEMU user network doesn\'t work well. ${RESTORE}
37echo ${YELLOW}:: HOWTO -\> https://serverfault.com/a/810639 ${RESTORE}
38echo ""
39echo ${YELLOW}:: Tip: If \'ping\' reports permission error, try reinstalling \'iputils\'. ${RESTORE}
40echo ${YELLOW}:: HOWTO -\> \'sudo dnf reinstall iputils\' ${RESTORE}
41echo ""
42
43sleep 2
44
45eval $cmd

Then run the script to start it directly:

chmod +x ./start_rvsp-ref_vm.sh
./start_rvsp-ref_vm.sh

Here are some key output excerpts:


OpenSBI v1.7
   ____                    _____ ____ _____
  / __ \                  / ____|  _ \_   _|
 | |  | |_ __   ___ _ __ | (___ | |_) || |
 | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
 | |__| | |_) |  __/ | | |____) | |_) || |_
  \____/| .__/ \___|_| |_|_____/|____/_____|
        | |
        |_|

Platform Name               : riscv-rvsp-ref,qemu # rvsp-ref is shown here
Platform Features           : medeleg
Platform HART Count         : 8
Platform IPI Device         : aia-imsic # using AIA advanced interrupt controller
Platform Timer Device       : aclint-mtimer @ 10000000Hz
Platform Console Device     : uart8250
Platform HSM Device         : ---
Platform PMU Device         : ---
Platform Reboot Device      : syscon-reboot
Platform Shutdown Device    : syscon-poweroff
Platform Suspend Device     : ---
Platform CPPC Device        : ---
Firmware Base               : 0x80000000
Firmware Size               : 403 KB
Firmware RW Offset          : 0x40000
Firmware RW Size            : 147 KB
Firmware Heap Offset        : 0x54000
Firmware Heap Size          : 67 KB (total), 4 KB (reserved), 13 KB (used), 49 KB (free)
Firmware Scratch Size       : 4096 B (total), 1400 B (used), 2696 B (free)
Runtime SBI Version         : 3.0
Standard SBI Extensions     : time,rfnc,ipi,base,hsm,srst,pmu,dbcn,fwft,legacy,dbtr,sse
Experimental SBI Extensions : none

Domain0 Name                : root
Domain0 Boot HART           : 1
Domain0 HARTs               : 0*,1*,2*,3*,4*,5*,6*,7*
Domain0 Region00            : 0x0000000000100000-0x0000000000100fff M: (I,R,W) S/U: (R,W)
Domain0 Region01            : 0x0000000010000000-0x0000000010000fff M: (I,R,W) S/U: (R,W)
Domain0 Region02            : 0x0000000002000000-0x0000000002007fff M: (I,R,W) S/U: ()
Domain0 Region03            : 0x000000000c000000-0x000000000c007fff M: (I,R,W) S/U: ()
Domain0 Region04            : 0x0000000024000000-0x0000000024007fff M: (I,R,W) S/U: ()
Domain0 Region05            : 0x0000000080000000-0x000000008003ffff M: (R,X) S/U: ()
Domain0 Region06            : 0x0000000080040000-0x000000008007ffff M: (R,W) S/U: ()
Domain0 Region07            : 0x0000000000000000-0xffffffffffffffff M: () S/U: (R,W,X)
Domain0 Next Address        : 0x0000000020000000
Domain0 Next Arg1           : 0x000000027fe00000
Domain0 Next Mode           : S-mode
Domain0 SysReset            : yes
Domain0 SysSuspend          : yes
...

# After successfully logging into the system, you can print some information:

[root@localhost ~]# fastfetch 
                 `.cc.`
             ``.cccccccc..`
          `.cccccccccccccccc.`
      ``.cccccccccccccccccccccc.``
   `..cccccccccccccccccccccccccccc..`
`.ccccccccccccccc/++/ccccccccccccccccc.`
:.cccccccccccccccmNMMNdo+oso+ccccccccccc.
:.cccccccccc/++odms+//+mMMMMm/:+syso/cccc
:.cccccccccyNNMMMs:::/::+o+/:cdMMMMMmcccc    root@localhost
:.ccccccc:+NmdyyhNNmNNNd:ccccc:oyyyo:cccc    --------------
:.ccc:ohdmMs:cccc+mNMNmyccccccccccccccccc    OS: openEuler 25.09 riscv64
:.cc/NMMMMMo////:c:///:cccccccccccccccccc    Host: riscv-rvsp-ref,qemu
:.cc:syysyNMNNNMNyccccccccccccccccccccccc    Kernel: Linux 6.6.0-102.0.0.5.oe2509.riscv64
:.cccccccc+MMMMMNyc:/+++/cccccccccccccccc    Uptime: 56 mins
:.cccccccccohhhs/comMMMMNhccccccccccccccc    Packages: 306 (rpm)
:.ccccccccccccccc:MMMMMMMM/cccccccccccccc    Shell: bash 5.2.37
:.ccccccccccccccccsNNNNNd+cccccccccccccc.    Cursor: Adwaita

Source information#

Summary#

Archive note#

Body#

Introduction to the RISC-V server reference platform specification#

RVSP-REF Spec 1.0 overview#

Hardware module specification overview#

1. Clock and timer#

2. Interrupt controller#

3. Input/output memory management unit (IOMMU)#

4. PCIe subsystem#

5. Reliability, availability, and serviceability (RAS)#

6. Quality of service (QoS)#

7. Performance monitoring#

8. Security#

QEMU RVSP-REF progress#

Booting openEuler on the QEMU rvsp-ref Machine#

Download QEMU#

Update the image#

Update the boot script#