This work has been submitted to the IEEE for possible publication. Copyright may be transferred without notice, after which this version may no longer be accessible.
Violet: Enabling Full Virtualization for M-mode RTOS on RISC-V Taro Kito1 , Ryosuke Yamamoto2 , Keisuke Horii2 , Hiroki Masuda2 , and Koichi Mouri1 1 Ritsumeikan University, Ibaraki, Osaka 567–8570, Japan (e-mail: [email protected], [email protected]) 2 Information Technology R&D Center, Mitsubishi Electric Corporation, Kamakura, Kanagawa 247–8501, Japan
(e-mail: [email protected], [email protected], [email protected]) Corresponding author: Taro Kito (e-mail: [email protected])
arXiv:2609.09833v1 [cs.OS] 9 Sep 2026
Abstract In embedded systems, complex configurations may be required, such as the simultaneous execution of a realtime operating system (RTOS) and a general-purpose operating system (GPOS), or the operation of multiple RTOS instances. Embedded system hypervisors have been studied and developed to meet these requirements for architectures like ARM and x86. RISC-V is experiencing growing adoption in embedded systems and faces similar needs. However, RISC-V’s virtualization support targets only U-mode (where applications run) and S-mode (where general-purpose OSs run) as virtualization levels. The M-mode, where RTOSs like FreeRTOS or Zephyr run, is excluded from virtualization. This means that, similar to architectures like ARM, running an RTOS on a Virtual Machine (VM) using methods based on virtualization support features is impossible. Therefore, this paper proposes the Violet hypervisor. Violet combines RISC-V’s virtualization features with software-based emulation, enabling the execution of unmodified M-mode RTOSs. Evaluation verified the validity of the M-mode emulation functionality using RISC-V architecture tests. Furthermore, this was implemented on the SiFive HiFive Premier P550 hardware, demonstrating that existing RTOSs can run on Violet’s VM and that coexistence with GPOSs like Linux is also possible. The performance evaluation also quantified the overhead introduced by M-mode emulation on M-mode CSR accesses, timer interrupt latency, and context switching.
Keywords: RISC-V, Hypervisor, Virtualization, Embedded System
1
Introduction
tualization. Therefore, existing M-mode RTOS binaries cannot be run on a VM without modification by using In embedded systems, complex configurations may be re- only hardware virtualization support features. quired, such as the simultaneous execution of a real-time Based on the above background, this paper sets the operating system (RTOS) and a general-purpose operat- following Research Questions (RQs): ing system (GPOS), or the operation of multiple RTOS instances. An RTOS is typically used for tasks requir• RQ1: Can a hypervisor be realized to run an existing ing real-time performance, while a general-purpose OS like M-mode RTOS on RISC-V without modification? Linux is used for tasks such as GUI or network operations. • RQ2: Does the mechanism used by the hypervisor Embedded hypervisors have been extensively studied and proposed in RQ1 to run existing M-mode RTOSs developed [1–4] to meet this demand for simultaneously comply with the RISC-V architecture? executing multiple OSs while managing and sharing such hardware resources. These embedded hypervisors leverage • RQ3: Can the hypervisor proposed in RQ1 enable processor virtualization features, such as those provided simultaneous execution of an M-mode RTOS and a by ARM, to reduce virtualization overhead when running GPOS on real RISC-V hardware? guest OSs. Furthermore, since they can run without modifying the guest OS, they offer high portability. • RQ4: What performance cost is incurred when runRISC-V is one of the processor architectures experining an existing M-mode RTOS on the hypervisor encing growing adoption in embedded and domain-specific proposed in RQ1? systems [5]. Embedded systems using RISC-V also have To address these RQs, a method for executing an similar needs for concurrently executing multiple OSs and running existing guest OSs without modification, and hy- RTOS operating in M-mode on a hypervisor was previpervisors effectively address them. However, running an ously investigated, and a hypervisor running on QEMU RTOS as a guest OS on RISC-V is challenging. RISC-V was implemented [8]. Building upon these results, this has three privilege levels: U-mode, S-mode, and M-mode. paper proposes Violet [9], an embedded hypervisor for However, RISC-V’s virtualization support targets only the RISC-V that enables RTOS execution on a VM without U-mode, where applications run, and the S-mode, where modification, allowing multiple OSs to run concurrently. general-purpose OSs run. The M-mode where RTOSs like Furthermore, the proposed hypervisor was implemented FreeRTOS [6] or Zephyr [7] run, is not a target for vir- on the SiFive HiFive Premier P550 [10] development
1
board, which features a RISC-V core, and its operation was verified. The contributions of this paper are as follows:
Applications
U-mode
System Calls
• Proposal of the Violet hypervisor by combining RISC-V’s virtualization support features with software-based M-mode processing emulation, enabling existing M-mode RTOSs to run without modification.
OS
S-mode
Firmware
M-mode
SBI
(a) GPOS
• Implementation of Violet on actual hardware, demonstrating concurrent execution of an M-mode RTOS (FreeRTOS) and a GPOS (Linux), while also evaluating the effectiveness of Violet’s M-mode emulation functionality.
RTOS
(b) RTOS
Figure 1: Privilege levels and software execution for GPOS and RTOS.
sip are interrupt pending registers. These CSRs perform the same functions but are accessible at different privilege • Quantitative evaluation of the performance overhead levels. Furthermore, mstatus, mie, and mip are supersets introduced by M-mode emulation on CSR accesses, of sstatus, sie, and sip, and also contain the bit fields of sstatus, sie, and sip. Therefore, by manipulating interrupt response, and context switching. mstatus, mie, and mip, it is possible to control interrupts This paper describes the background and challenges in S-mode. Conversely, manipulating sstatus, sie, and in Section 2, presents the proposed hypervisor Violet in sip does not allow control of interrupts in M-mode. Section 3, and evaluates Violet in Section 4. Section 5 covers related works, and Section 6 concludes the paper. 2.3 Interrupt Controllers Many RISC-V processors incorporate the Core-Local Interruptor (CLINT) and the Platform-Level Interrupt Controller (PLIC) as their interrupt controllers. 2.1 Overview of RISC-V CLINT is an interrupt controller that manages software interrupts and timer interrupts in RISC-V [13]. RISC-V is an open Instruction Set Architecture (ISA) deCLINT is locally connected to each CPU core and conveloped at the University of California, Berkeley [11, 12]. tains registers for raising software and timer interrupts. It is license-free, allowing anyone to freely use, impleThese are accessible via Memory-Mapped I/O (MMIO). ment, and extend it. The RISC-V instruction set has CLINT is often managed by firmware operating in a modular structure consisting of a base integer instrucM-mode, such as OpenSBI [14], so an OS operating in Stion set (RV32I for 32-bit or RV64I for 64-bit) combined mode cannot directly manipulate CLINT. Therefore, the with optional extensions such as the multiplication extenOS operates CLINT via the Supervisor Binary Interface sion (M), atomic extension (A), floating-point extensions (SBI). The SBI is described in Section 2.4. (F/D), and compressed instruction extension (C). PLIC [15] is an interrupt controller that manages exRISC-V has three distinct privilege levels [12]: Mternal interrupts in RISC-V. Registers exist to enable/dismode, S-mode, and U-mode. M-mode represents Machine able interrupts, set priorities, and check pending interrupt mode, S-mode represents Supervisor mode, and U-mode status per CPU core or privilege level, accessed via MMIO. represents User mode. M-mode has the highest privilege, Using PLIC enables interrupt distribution among multiple S-mode has the next highest privilege, and U-mode has CPU cores and interrupt control per privilege level. the lowest privilege. Depending on the privilege level, the executable privileged instructions, accessible Control and Status Registers (CSRs), and memory regions are re- 2.4 Supervisor Binary Interface (SBI) stricted. SBI [16] is a specification that abstracts platform-specific functionality in RISC-V and provides an interface between 2.2 Control and Status Registers (CSRs) the OS and firmware. Through SBI, the OS can operCSRs are registers used to indicate or control the state of ate hardware resources such as interrupts and timers in the CPU. Table 1 shows the major RISC-V CSRs, their a hardware-independent manner. SBI is implemented by descriptions, and the privilege levels at which they are ac- firmware running in M-mode, and an OS running in Scessible. CSRs accessible only in M-mode have prefixes mode sends requests to the firmware via SBI.
2
Background and Challenge
starting with ”m”, while those accessible in S-mode or higher have prefixes beginning with ”s”. mstatus and sstatus are registers that control the CPU state, while mepc and sepc are registers that store the PC value at the time of an exception. mtvec and stvec are registers specifying trap vector addresses, while mcause and scause indicate exception/interrupt causes. The registers mie and sie are interrupt enable registers, and mip and
2.5
Execution Privilege Levels of GPOS and RTOS
Figure 1(a) shows the relationship between privilege levels and the software that operates when executing a GPOS, and Figure 1(b) shows the corresponding relationship for an RTOS. As shown in Figure 1(a), when executing a
2
Table 2: VS-mode CSRs and their corresponding S-mode CSRs. VS-mode CSRs S-mode CSRs vsepc sepc vsstatus sstatus vstvec stvec vscause scause vsie sie vsip sip
Table 1: CSRs (Control and Status Registers) and their accessible privilege levels. Accessible privilege levels mstatus Register to control CPU status, M sstatus such as interrupt enable. M, S mepc Register indicating the PC value M M, S sepc when an exception occurs. mtvec Register that specifies M stvec the address of the trap vector. M, S mcause Register indicating M scause the cause of the exception/interrupt. M, S mie Interrupt enable register. M sie M, S mip Interrupt pending register. M sip M, S CSRs
Description
VU-mode
2.6.1
Hypervisor
HS-mode is the privileged level at which the hypervisor operates. HS-mode replaces S-mode when Hypervisor Extension is enabled. HS-mode adds CSR and hypervisor instructions to S-mode. Registers for controlling the two-stage address translation of the Memory Management Unit (MMU), used to isolate and protect memory spaces between guest OSs and between guest OSs and the hypervisor, as well as registers for managing the VM state, are added.
Firmware
2.6.2
Applications System Calls
VS-mode
Guest OS SBI
HS-mode
HS-mode
SBI
M-mode
VS-mode is the privilege level at which the guest OS operates on the guest VM. VS-mode is a virtualized privilege level of S-mode, providing the same set of CSRs and privileged instructions as S-mode. However, in practice, the hypervisor provides and manages a dedicated set of CSRs for VS-mode. When a guest OS attempts to access S-mode CSRs in VS-mode, the hardware translates this access to VS-mode CSRs. Table 2 shows this mapping. For example, an attempt to access sstatus is translated into an access to vsstatus. Therefore, even if the guest OS executes S-mode privileged instructions or references CSRs, no exception occurs, and no hypervisor trap is required. Furthermore, VU-mode is the privilege level at which user programs run on the guest OS.
Figure 2: Privilege levels and software execution when Hypervisor Extension is enabled. GPOS, firmware such as OpenSBI [14] operates in Mmode, a GPOS such as Linux [17] operates in S-mode, and applications operate in U-mode. U-mode applications invoke system calls to transition to S-mode and request processing from the OS. The S-mode OS uses SBI to request hardware-specific operations from the M-mode firmware. In contrast, as shown in Figure 1(b), RTOSs such as FreeRTOS and Zephyr run in the highest privilege level, M-mode. Therefore, an RTOS directly accesses M-mode CSRs, interrupt controllers, and other hardware resources, and typically does not use SBI.
2.6
Hardware Virtualization Hypervisor Extension
VS-mode and VU-mode
2.7
Support:
Challenge RTOS
in
Executing
M-mode
By utilizing the Hypervisor Extension described in Section 2.6, multiple hypervisors exist for RISC-V that execute an OS normally operating in S-mode within VSmode, [18–21]. However, as shown in Figure 3, the Hypervisor Extension targets S-mode and U-mode for virtualization. There is no mechanism to virtualize M-mode registers or privileged instructions. Thus, because the Hypervisor Extension does not virtualize M-mode, the hypervisor above cannot run M-mode programs. Therefore, as discussed in Section 2.5, while RTOSs designed to run in M-mode exist, existing RISC-V hypervisors cannot support running multiple such RTOSs or simultaneously running a general-purpose OS and an RTOS.
The RISC-V privileged architecture specification defines the Hypervisor Extension as hardware support for hypervisor implementation [12]. The Hypervisor Extension adds new privilege levels for hypervisors and VMs, along with corresponding CSRs and hypervisor instructions. Figure 2 illustrates the relationship between privilege levels and the software that operates at each level when the Hypervisor Extension is enabled. Furthermore, since the hypervisor appears to guest OSs as privileged software equivalent to firmware, it must provide SBI. Guest OSs use SBI to configure timers and control interrupts between cores. The hypervisor virtualizes these SBI requests when required.
3
When running GPOS
Applications
VU-mode
U-mode
Applications
Guest GPOS
VS-mode
S-mode
GPOS
Hypervisor
HS-mode
M-mode
Firmware
Firmware
M-mode
When running RTOS
RTOS
Not subject to virtualization Privilege levels when OS runs on bare metal
Privilege levels when the H-extension is enabled
Figure 3: Privilege levels that are virtualized and those that are not. VU-mode
Applications
VS-mode
GPOS
Virtualized architecture
U-mode
Virtualized architecture RTOS
RTOS
Applications
U-mode
M-mode Emulator S-mode
GPOS
M-mode
Firmware
HS-mode
S-mode
Violet
M-mode
OpenSBI (Firmware)
M-mode
RTOS
RISC-V Core
Figure 4: Overview of Violet.
3
Violet
3.1
Overview
– Except for specific devices, Violet adopts a pass-through mode that allows guest OSs running in VS-mode to directly access assigned devices, minimizing virtualization overhead.
Violet [9] is an embedded hypervisor for RISC-V. Figure 4 shows an overview of Violet. In this architecture, Violet operates in HS-mode, while OpenSBI [14] operates as 3.2 Execution of GPOS firmware in M-mode. The following summarizes Violet’s As usual, GPOS operating in S-mode runs on a VM using features for executing guest OSs in this configuration. the Hypervisor Extension. The guest GPOS runs in VSmode, with applications operating in VU-mode. As de• Capable of executing GPOS operating in S-mode scribed in Section 2.6, S-mode privileged instructions are – GPOS operating in S-mode runs as a guest OS available in VS-mode, and all accesses to S-mode CSRs in VS-mode using the virtualization support are hardware-translated into accesses to VS-mode CSRs. Therefore, software’s virtualization of CPU features is unfeatures of the Hypervisor Extension. necessary. Furthermore, the guest GPOS can access mem• Capable of executing RTOS operating in M-mode ory via its virtual and physical address spaces using twostage address translation. – RTOS operating in M-mode runs as a guest OS in VS-mode by combining the virtualization support features of the Hypervisor Exten- 3.2.1 SBI Virtualization sion with the M-mode Emulator. The guest OS uses SBI to configure timers and control interrupts between cores, so Violet implements and pro• Capable of simultaneously executing multiple OSs vides SBI. The hypervisor virtualizes and processes re– By executing each guest OS as an independent quests via SBI, forwarding them to OpenSBI as necessary. VM in VS-mode, co-execution of GPOS and This makes it appear to the guest GPOS running in VSRTOS, or execution of multiple RTOSs, is pos- mode that the firmware implementing SBI is running in M-mode. sible. • Provides full virtualization
3.2.2
– Violet provides a virtualized hardware environment to guest OSs running in VS-mode, enabling execution on a VM without requiring modifications to the guest OS.
Device Pass-through
The memory spaces of guest OSs, including device MMIO regions, are isolated by the two-stage address translation of the Hypervisor Extension. For device access, except for the PLIC external interrupt controller, Violet maps the MMIO regions statically assigned to each guest OS into its guest physical address space, thereby enabling
• Device access employs pass-through mode
4
Mode
Table 3: M-mode instructions that need to be emulated. Instruction Description ECALL Environment call raises an environment call exception (For system calls and SBI calls) MRET Return from M-mode into M/S/U-mode (Return from trap handler)
RTOS VS-mode Trap
HS-mode
M-mode Privileged Instructions Privileged Instruction Emulation
Mode
Interrupt Virtual M-mode CSRs
U-mode
VCLINT
M-mode Emulator
S-mode
Violet M-mode
OpenSBI (Firmware)
RTOS
M-mode Interrupt
M-mode CSR
CLINT
RISC-V H/W
M-mode CSR
CLINT
RISC-V H/W
• Emulation of CSR accesses Actual architecture
Virtualized architecture
• Emulation of interrupts and exceptions
Figure 5: M-mode Emulator Overview.
• Emulation of CLINT 3.4.1
direct access to the assigned devices. This mechanism controls whether a guest can access statically assigned address ranges; it does not control interference through shared hardware resources such as shared caches or memory bandwidth. Such bandwidth or QoS control would require hardware that implements RISC-V QoS specifications such as Ssqosid or CBQRI [22, 23]. However, hardware implementations of these specifications are not currently available; therefore, strict interference isolation for shared hardware resources is outside the scope of this work. 3.2.3
When executing RTOS or bare-metal programs on a VM using Violet’s M-mode Emulator, these M-mode software programs run in VS-mode. VS-mode is a virtualization of S-mode and operates at a lower privilege level than Mmode. Therefore, executing M-mode privileged instructions in VS-mode is impossible and results in an Illegal Instruction exception. The M-mode Emulator traps this exception and emulates the M-mode privileged instruction, enabling the execution of M-mode privileged instructions within VS-mode. Table 3 shows the M-mode privileged instructions requiring emulation. ECALL is an instruction that performs an environment call. Normally, when ECALL executes in M-mode, an Environment Call from M-mode exception occurs, and the execution jumps to the M-mode trap handler. However, when an RTOS executes ECALL on Violet’s VM, an Environment Call from VS-mode exception occurs, causing a jump to Violet’s trap handler in HS-mode. Therefore, Violet must trap ECALL when executed in VSmode and emulate it to behave identically when ECALL is executed in M-mode. Specifically, Violet in HS-mode traps the Environment Call from VS-mode exception raised by executing ECALL in VS-mode. It then invokes the guest RTOS trap handler in VS-mode to emulate ECALL. Furthermore, since the exception type raised differs from the original, separate exception emulation is required. This is explained in Section 3.4.3. MRET is a privileged instruction that returns from Mmode to M/S/U-mode, primarily used for returning from trap handlers. Since this instruction can only be executed in M-mode, executing MRET in VS-mode causes an Illegal Instruction exception. The M-mode Emulator emulates MRET by trapping this exception and replacing it with an SRET instruction for execution. Figure 6 shows the emulation flows for ECALL and MRET. In Fig. 6(a), when the guest RTOS executes ECALL in VS-mode, an Environment Call from VS-mode exception occurs and control transfers to Violet’s trap handler in HSmode. Violet then sets the guest exception state so that the event appears as the exception handling that would occur after executing ECALL in M-mode, and resumes execution at the guest RTOS trap handler. In Fig. 6(b), when the guest RTOS executes MRET in VS-mode, an Illegal Instruction exception occurs and Violet catches it.
PLIC Virtualization
PLIC can notify software running in M-mode and S-mode of external interrupts. However, it cannot notify guest operating systems operating in VS-mode of external interrupts. To virtualize PLIC, interrupts intended for S-mode must be trapped each time and converted into interrupts for VS-mode for notification. At this point, the PLIC state the guest OS assumes may differ from the actual PLIC state. Therefore, instead of allowing the guest OS to use the PLIC directly, Violet utilizes a Virtual PLIC (VPLIC).
3.3
Execution of RTOS
Existing RISC-V hypervisors cannot execute unmodified RTOSs designed to run in M-mode. Violet enables such RTOSs to run on a VM. Violet combines the virtualization support features of the Hypervisor Extension with an Mmode Emulator to emulate M-mode within VS-mode. The RTOS operates within this emulation environment.
3.4
Emulation of Privileged Instructions
M-mode Emulator
Figure 5 shows an overview of the M-mode Emulator. As discussed in Section 2.7, RISC-V’s Hypervisor Extension excludes M-mode from virtualization. Consequently, unlike other architectures, running an RTOS on a VM is impossible using virtualization support features. Therefore, Violet provides an M-mode Emulator that runs the RTOS on a VM by emulating M-mode in software. To virtualize M-mode, it provides the following features: • Emulation of privileged instructions
5
ECALL emulation flow
Guest OS (VS-mode)
Guest RTOS executes ECALL
MRET emulation flow
Guest trap handler
Guest OS (VS-mode)
Guest RTOS executes MRET
Continue execution
sret
Trap handler (Illegal instruction)
sret
Violet (HS-mode)
Trap handler (e call from VS-mode)
Redirect to guest updates PC/status
Instruction decode
MRET emulation updates status/PC
Violet (HS-mode)
(a) ECALL emulation
(b) MRET emulation
Figure 6: Privileged Instructions emulation flows. Violet restores the return destination and interrupt state from the virtualized M-mode state, and returns to VSmode guest execution using SRET. 3.4.2
M-mode CSR access emulation flow
Guest OS (VS-mode)
Continue execution
Guest RTOS executes CSR instruction
Emulation of CSR accesses Trap handler (Illegal instruction)
An Illegal Instruction exception occurs when access to the CSR in M-mode occurs in VS-mode. Implementing a virtual CSR within the M-mode Emulator and emulating access to the M-mode CSR enables access to the M-mode CSR in VS-mode. The CSR that requires virtualization is classified into three categories (a) to (c) for explanation.
Instruction decode
Violet (HS-mode)
sret
CSR replace / emulation
CSR access
Figure 7: M-mode CSR access emulation flow. 63 13
mstatus
12
11
MPP [1]
MPP [0]
10
9
8
7
SPP
MPIE
6
5 SPIE
4
3
2
MIE
1
0
SIE
(a) CSRs replaceable with VS-mode CSRs These CSRs can be emulated by replacing accesses Convert to them with accesses to VS-mode CSRs, since VS0 mode also implements CSRs with equivalent funcSPP SPIE SIE vsstatus tionality. For example, access to the mtvec register 63 12 11 10 9 8 7 6 5 4 3 2 1 can be emulated by mapping it to the vstvec register. However, CSRs such as mstatus and mcause require value conversion during both write and read opera- Figure 8: Conversion of values between mstatus and vsstations because the values stored in the corresponding tus. VS-mode CSRs are not identical. Figure 7 shows the emulation flow for M-mode CSR accesses. When the guest RTOS accesses an M-mode CSR in VS-mode, an Illegal Instruction exception occurs and control transfers to Violet’s trap handler. Violet decodes the trapping instruction and determines both the target CSR and the access type. If the target CSR is implemented as a virtual CSR, Violet reads or writes the virtual CSR inside the M-mode Emulator. If the target CSR can be replaced with a VS-mode CSR, Violet converts the bit fields as needed and accesses the corresponding VS-mode CSR. After the emulation, Violet advances the guest program counter and returns control to the guest RTOS in VSmode. The bit-field conversions used for interrupt-related CSRs are detailed in Figs. 8–10.
(b) PMP-related CSRs These CSRs are related to Physical Memory Protection (PMP). M-mode software manipulates these CSRs to control memory access via PMP. However, since access to PMP-related CSRs is not possible from VS-mode or S-mode, Violet must emulate both these CSR accesses and the memory protection provided by PMP. Similarly, where Violet operates in HS-mode, it cannot manipulate PMP-related CSRs. Therefore, it cannot perform memory protection using PMP, but it can emulate it using paging. (c) Read-only CSRs Since these CSRs are read-only registers, Violet emulates access to them by returning arbitrary values.
3.4.3
In Violet’s M-mode Emulator, the following registers from categories (a) and (c) were implemented as virtual registers: mhartid, mstatus, mie, mip, mcause, mepc, mtvec, mideleg, medeleg, mtval, mscratch, and misa. Accessing these registers triggers an Illegal Instruction exception. Violet traps this exception, performs appropriate emulation for each register, and returns control to the guest OS.
Interrupt and Exception Emulation
Table 5 shows interrupts and exceptions for M-mode and interrupts and exceptions for S-mode. RTOS and baremetal programs designed to run in M-mode utilize interrupts and exceptions specific to M-mode. Therefore, they cannot utilize these interrupts and exceptions when running in VS-mode. Consequently, the M-mode Emulator must convert interrupts and exceptions intended for M6
63 12
mie
11
10
MEIE
9
8
SEIE
7
6
MTIE
5
4
STIE
3
2
MSIE
1
0
Guest OS (VS-mode)
SSIE
Convert
Trap handler (page fault trap)
0
vsie
SEIE 63 12
11
10
9
STIE 8
7
6
5
3
2
Continue execution
VPLIC emulation
Target?
sret
Violet (HS-mode)
SSIE 4
Guest RTOS CLINT/PLIC MMIO
VCLINT emulation
1 set timer via SBI
Figure 9: Conversion of values between mie and vsie. 63 12
mip
11
10
MEIP
9
8
SEIP
7
6
MTIP
5
4
STIP
3
2
MSIP
1
Firmware / Hardware
0
Physical CLINT
set state via MMIO
Physical PLIC
Figure 11: CLINT/PLIC MMIO emulation flow.
SSIP
Guest OS (VS-mode)
Convert
Guest trap handler
0
vsip
SEIP 63 12
11
10
9
STIP 8
7
6
5
SSIP 4
3
2
Trap handler (Supervisor external interrupt)
1 Violet (HS-mode)
VPLIC emulation 2
Trap handler (Supervisor timer interrupt)
Figure 10: Conversion of values between mip and vsip.
sret
update state vis SBI
mode into those for VS-mode. To convert interrupts and exceptions, Violet traps accesses to the mstatus, mie, and mcause registers. It then hooks the read and write operations on these values to perform the conversion. Emulation of the CSR (category (a) as described in 3.4.2) enables this functionality. The mstatus register contains the mstatus.MIE field, which sets interrupt enable/disable. Setting this to 1 globally enables interrupts for M-mode. However, since interrupts used on the VM are actually for VS-mode, it is necessary to enable interrupts for VS-mode, not M-mode. Therefore, when the guest RTOS writes a value to mstatus, Violet traps this operation, converts the mstatus value, and writes it to vsstatus. Figure 8 shows the mapping between the bit fields of mstatus to be converted and the bit fields of vsstatus. For example, setting mstatus.MIE is converted to setting vsstatus.SIE. When mstatus is read, the value of vsstatus is converted to the corresponding bit field in mstatus and returned. Similarly, the mip and mie registers are virtualized by mapping them to the corresponding bit fields in the vsip and vsie registers. Since the mip register is used to insert interrupts for M-mode by type, and the mie register is used to enable or disable interrupts, these must be converted for VS-mode. Figure 9 and Figure 10 show the bitfield mappings between mie and vsie, and between mip and vsip. Read and write operations are performed by converting according to this mapping. Figure 11 shows the MMIO access flow in CLINT/PLIC emulation. When the guest RTOS accesses the MMIO region of CLINT or PLIC, a page fault occurs and control transfers to Violet in HS-mode. Violet determines whether the access targets CLINT or PLIC, and dispatches the access to the VCLINT or VPLIC emulation path. The emulation path updates the guestvisible CLINT/PLIC state and, if necessary, configures the physical CLINT/PLIC state through SBI or MMIO
Firmware / Hardware
1
Interrupt
3
VCLINT emulation
update state via MMIO
Physical CLINT Physical PLIC
Figure 12: Interrupt injection flow. before resuming guest execution. Figure 12 shows the interrupt-injection flow. When an interrupt arrives from the physical CLINT or PLIC, Violet’s trap handler first receives the interrupt in HS-mode. Violet then updates the VCLINT or VPLIC state, sets the corresponding VSmode interrupt-pending state, and injects the interrupt into the guest RTOS. Because the guest RTOS reads the state converted as an M-mode interrupt through CSR emulation, it can handle the interrupt as if it had been received in M-mode. On the other hand, the mcause register stores the cause of the interrupt or exception. It is a register referenced within interrupt and exception handlers, used by software to identify the interrupt or exception that occurred. Although the interrupts and exceptions that actually occur are intended for VS-mode, to make it appear as if an interrupt or exception intended for M-mode has occurred, it is necessary to convert the corresponding VS-mode interrupts and exceptions to M-mode interrupts and exceptions, as shown in Table 5. Table 4 shows the corresponding cause names, cause numbers, and actual values for mcause and vscause. 3.4.4
CLINT Emulation
In some cases, M-mode firmware, such as OpenSBI, restricts memory access to specific regions or memorymapped devices. Specifically, access to CLINT, which controls timers and inter-core interrupts, is restricted. Therefore, Violet operating in HS-mode or a guest OS operating in VS-mode cannot access them. However, since RTOSs, which inherently operate in M-mode, directly manipulate CLINT 7
Table 4: Conversion of cause values between guest-visible mcause and internal vscause. Guest-visible M-mode cause mcause value Internal VS-mode cause vscause value Machine software interrupt Supervisor software interrupt 0x8000000000000003 0x8000000000000001 (interrupt, no. 3) (interrupt, no. 1) Machine timer interrupt Supervisor timer interrupt 0x8000000000000007 0x8000000000000005 (interrupt, no. 7) (interrupt, no. 5) Machine external interrupt Supervisor external interrupt 0x800000000000000b 0x8000000000000009 (interrupt, no. 11) (interrupt, no. 9) Environment call from M-mode Environment call from VS-mode 0x000000000000000b 0x0000000000000009 (exception, no. 11) (exception, no. 9)
Table 5: Interrupts and exceptions for M-mode and VS- Table 6: Test environment and relevant hardware specifications. mode. For M-mode For VS-mode Item Description Machine software Supervisor software Board SiFive HiFive Premier P550 [10] interrupt interrupt SoC Eswin EIC7700X Quad-core SiFive P550, 1.4 GHz CPU Machine timer interrupt Supervisor timer interrupt Memory 16 GB LPDDR5 Machine external Supervisor external Violet Hypervisor interrupt interrupt Guest OS Linux, FreeRTOS, Environment call Environment call Test programs (riscv-arch-test) from VS-mode from M-mode
to control timer interrupts and inter-core interrupts, Violet provides a virtualized CLINT, called Virtual CLINT (VCLINT), to RTOSs operating in VS-mode. VCLINT implements the mtime register and the mtimecmp register to control timer interrupts, just like the actual CLINT. When accessing CLINT from VS-mode, this access is replaced with access to VCLINT. VCLINT operates the CLINT via SBI to set the timer when its registers are manipulated.
4.1
Functional Evaluation
4.1.1
Architecture-Test-Based Evaluation of the M-mode Emulator
This subsubsection evaluates whether the M-mode execution environment provided by the M-mode Emulator behaves consistently with the RISC-V specification using RISCOF and riscv-arch-test. RISCOF [24] is a test framework for evaluating RISCV specification compliance, and riscv-arch-test [25] is a test suite that provides test programs for the RISC-V 4 Evaluation specification. Based on the implemented RISC-V extensions and privilege levels described in a configuration file, This section evaluates whether the M-mode Emulator pro- RISCOF selects tests corresponding to the implementavides an M-mode execution environment consistent with tion under test from the riscv-arch-test pool and collects the RISC-V specification using RISC-V architecture tests. the results. In this evaluation, VioletVM is configured as It also evaluates whether the proposed hypervisor, Violet, a RISC-V implementation that implements only M-mode, can run an RTOS operating in M-mode and support a and the selected tests are executed on Violet’s VM. mixed environment of RTOS and GPOS. It further evaluates the performance overhead introduced by the M-mode Configuration Figure 13 shows the contents of the Emulator. RISCOF configuration file (p550 violetvm isa.yaml) used The evaluation items are as follows. in this study. This configuration file defines the execution environment on a VM with Violet’s M-mode • Functional evaluation Emulator enabled as a RISC-V implementation named – Architecture-test-based evaluation of the M- VioletVM. The implemented RISC-V extension is specimode Emulator fied as RV64IMAFDCZicsr Zifencei. This is the extension implemented in the RISC-V core of the SiFive HiFive – Evaluation of FreeRTOS execution Premier P550 used for testing, excluding the S-mode, U– Evaluation of concurrent execution of Linux mode, and Hypervisor Extension privilege levels, making and FreeRTOS it a RISC-V implementation with only M-mode. With this configuration file, RISCOF executes the tests • Evaluation of performance overhead required for a RISC-V implementation that implements Each evaluation item is described below. Table 6 shows only M-mode on a Violet VM with the M-mode Emulator the test environment and the relevant hardware specifica- enabled. tions.
8
hart_ids : [0] hart0 : ISA : R V 6 4 I M A F D C Z i c s r _ Z i f e n c e i physical_addr_sz : 51 Us er_ Spe c_V ersi o n : ’2.3 ’ supported_xlen : [64]
Table 7: Test Results. Test case Count PASSED 664 Integer Instructions Floating Point Instructions Double Floating Point Instructions Atomic Instructions Compressed Instructions (except breakpoint) ECALL Instruction FENCE Instruction FAILED 10 Misaligned Load/Store Instruction Breakpoint Instruction (include Compressed Instructions)
Figure 13: RISCOF Configuration for VioletVM. Test Results Table 7 shows the RISCOF test results. Out of 674 tests conducted, 664 were PASSED, and 10 were FAILED. The passed tests covered integer instructions, singleprecision floating-point instructions, double-precision floating-point instructions, compressed instructions (excluding breakpoint), atomic instructions, ECALL instructions, and FENCE instructions. In particular, the ECALL instruction tests check exception handling caused by ECALL and the behavior of the exception-related CSRs updated during this process. Passing these tests indicates that the M-mode Emulator performs ECALL emulation, exception handling, and updates to the exception-related CSRs as expected. The 10 failed tests targeted misaligned load/store instructions and breakpoint instructions, as explained below. The Misaligned Load/Store Instruction tests check whether Load Address Misaligned or Store/AMO Address Misaligned exceptions are raised for load/store instructions to unaligned addresses. However, for RISC-V implementations that do not raise these exceptions, these tests always FAIL and the results can be ignored [25]. Violet runs on OpenSBI, which executes in M-mode. OpenSBI traps these exceptions, emulates the memory accesses, and returns the results to Violet running in HS-mode. As a result, from the perspective of software running on the guest VM, VioletVM behaves as an implementation that does not raise exceptions for misaligned accesses. Therefore, these test results can be ignored. The Breakpoint Instruction tests are for the breakpoint instruction. Since Violet does not virtualize the Breakpoint instruction, these tests always FAIL. Therefore, this result is expected and does not affect the functional evaluation. For these reasons, the failed tests are either outside the scope of this evaluation or can be ignored. Since all other tests passed, the results confirm that VioletVM exhibits the expected behavior as an M-mode execution environment within the scope covered by riscv-arch-test.
Mode
VS-mode
FreeRTOS (Virtual M-mode)
Virtual M-mode CSRs
HS-mode
VCPU 0 VCLINT Interrupt SBI
M-mode
Pass-through
Violet OpenSBI
PCPU 0 UART0 Devices
EIC7700X (SoC)
Figure 14: Overview of FreeRTOS execution on Violet.
then outputs messages from the UART at regular intervals using timer interrupts. Successful execution of this sample program demonstrates that basic functions such as memory allocation to Violet’s VM, trapping of interrupts and exceptions, and interrupt virtualization operate normally. Furthermore, since FreeRTOS is an RTOS that runs in M-mode, successful execution also indicates that Violet’s M-mode Emulator, which performs M-mode CSR virtualization and privileged instruction emulation, is operating correctly. As the execution result, Figure 15 shows the execution 1 is the output log. This log was output using UART. ○ 2 is the output from Vifrom the firmware OpenSBI, ○ 4.1.2 Evaluation of FreeRTOS Execution 3 olet, and the subsequent output is from FreeRTOS. ○ is the sample program output that periodically outputs This subsubsection evaluates whether FreeRTOS and its sample program [26] can execute on the virtual machine. messages using UART via timer interrupts. This shows Figure 14 shows the operating environment. VCPU0 that the M-mode Emulator, including M-mode CSR virtuis assigned to PCPU0, and FreeRTOS runs on it. In this alization, privileged instruction emulation, and interrupt case, the virtual M-mode realized by Violet’s M-mode em- virtualization, is operating normally. ulation function is used. Only CLINT, which handles timer interrupts, is virtualized, while other devices, such 4.1.3 Evaluation of Concurrent Execution of Linux and FreeRTOS as UART, are passed through. The FreeRTOS sample program to be executed disThis subsubsection evaluates concurrent execution of plays ”Hello FreeRTOS!” using UART at startup, and Linux and FreeRTOS on Violet. Figure 16 shows the op9
Boot HART MIDELEG : 0 x 0 0 0 0 0 0 0 0 0 0 0 0 2 6 6 6 Boot HART MEDELEG : 0 x 0 0 0 0 0 0 0 0 0 0 f 0 0 5 0 9 Violet bootloader Hello I ’ m Violet Hypervisor 2 Hello FreeRTOS ! 0: Tx : Transfer1 0: Rx : Blink1 3 0: Tx : Transfer2 0: Rx : Blink2
0: Rx : Blink2 0: Tx : Transfer1 ubuntu@ubuntu :~ $ uname -a Linux ubuntu 6.6.21 -9 - premier #1 SMP PR EE M PT _D YNAMIC Sat Nov 9 00:21:16 UTC 2024 riscv64 riscv64 riscv64 GNU / Linux ubuntu@ubuntu :~ $ 0: Rx : Blink1 0: Tx : Transfer2 0: Rx : Blink2 0: Tx : Transfer1 1 0: Rx : Blink1 0: Tx : Transfer2
1
Figure 15: Log of FreeRTOS execution on Violet.
Figure 17: Log of multiple VMs execution. Mode VU-mode
Applications
VS-mode
Linux VCPU 0
HS-mode
for each measured M-mode CSR do for each supported operation in {read, write} do for i = 1 to 10000 do start ← rdcycle() execute CSR operation end ← rdcycle() sample[i] ← end − start end for discard the first sample compute min, max, average, and median end for end for
FreeRTOS VCPU 0
VPLIC
VCLINT
VM 1 (M-mode Emulator Enabled)
VM 0 Violet Pass-through
M-mode
OpenSBI
Pass-through
PCPU 0 PLIC
PCPU 1 UART0
I2C MMC
CLINT
USB
SPI
Devices
Figure 18: Pseudocode of the CSR access latency measurement.
EIC7700X (SoC)
Figure 16: Overview of multiple VMs execution on Violet. 4.2.1 erating environment when running multiple VMs. Here, VCPU0 of VM0 is assigned to PCPU0, and Linux runs on it. Also, VCPU0 of VM1 is assigned to PCPU1, and FreeRTOS runs on it. For interrupt controller virtualization and device allocation, all devices except PLIC are passed through to the Linux guest of VM0 and assigned to it. All devices, except CLINT, are passed through and assigned to the FreeRTOS guest in VM1. UART0 is shared between VM0 and VM1 only for log output in this evaluation. As the execution result, Figure 17 shows the execution log. The logs until each guest OS starts up are omitted. 1 is the output of the This log was output using UART. ○ FreeRTOS sample program on VM1. The rest is the Linux log on VM0. These results show that Linux and FreeRTOS run simultaneously on their respective VMs. The mixed log is due to the sharing of UART0.
M-mode CSR Access Latency
The cycle count required for CSR read and write accesses was measured for the M-mode CSRs implemented by the M-mode Emulator. Figure 18 shows the measurement procedure as pseudocode. In this measurement, the cycle counter was read before and after each CSR access instruction using rdcycle, and the difference was recorded as the CSR access latency. This procedure was repeated 10000 times for each measured CSR read and write operation, and the first sample was excluded to reduce the effect of the initial cache miss. Table 8 shows the CSR access latency on VioletVM in cycles. Because mhartid is a read-only CSR, the write-latency entries are marked as N/A. Table 8 shows that accesses to the M-mode CSRs implemented by the M-mode Emulator have average latencies of approximately 1000 to 1800 cycles. Table 9 shows the overhead of representative CSR accesses relative to an M-mode bare-metal baseline. The overhead is calculated 4.2 Evaluation of Performance Overhead by subtracting the average latency on M-mode bare metal from the average latency on VioletVM. For the represenThis subsection evaluates the performance overhead intro- tative CSR accesses, the M-mode Emulator introduces an duced by Violet’s M-mode Emulator. In Violet, M-mode additional overhead of approximately 1088 to 1658 cycles. CSR accesses and interrupt handling by the guest OS are This overhead occurs because M-mode CSR accesses by trapped and handled by the M-mode Emulator. There- the guest OS are trapped by Violet and processed in softfore, the overhead of M-mode CSR accesses can affect in- ware by the M-mode Emulator. terrupt handling and RTOS scheduling behavior. This evaluation measures M-mode CSR access latency, timer 4.2.2 Timer Interrupt Latency interrupt latency, and context-switch performance using the Thread-Metric Testsuite. Timer interrupt latency was measured to evaluate the effect on RTOS interrupt response. This measurement records the time from the occurrence of a timer interrupt to the arrival at the RTOS timer interrupt handler. Figure 19 shows the measurement interval for timer 10
Table 8: M-mode CSR access latency on VioletVM (cycles). Read Read Read Write Write Write CSR Min Max Avg. Min Max Avg. mcause 1345 1818 1361.16 1345 1848 1358.05 medeleg 1320 1924 1457.18 1324 1978 1465.66 mepc 1326 2000 1361.76 1328 1804 1378.52 mhartid 1069 1699 1075.00 N/A N/A N/A mideleg 1338 1848 1360.93 1342 1776 1358.95 mie 1096 1590 1107.11 1092 1722 1105.41 mip 1344 1844 1479.20 1344 2018 1478.84 misa 1332 2006 1403.65 1340 1870 1387.85 mscratch 1350 1827 1382.78 1348 1930 1387.53 mstatus 1628 2126 1671.50 1101 1398 1110.49 mtval 1330 2016 1389.22 1339 1884 1387.13 mtvec 1586 2164 1772.32 1588 2356 1775.89
Figure 19: Cycle-count measurement interval for timer interrupt latency on bare metal.
Table 9: Representative M-mode CSR access latency on M-mode bare metal and VioletVM (cycles). OverCSR Op. Env. Min Max Avg. head M-mode mcause Read 14 14 14.00 0.00 bare metal mcause Read VioletVM 1345 1818 1361.16 1347.16 M-mode mstatus Read 14 14 14.00 0.00 bare metal mstatus Read VioletVM 1628 2126 1671.50 1657.50 M-mode mcause Write 14 14 14.00 0.00 bare metal mcause Write VioletVM 1345 1848 1358.05 1344.05 M-mode mstatus Write 22 22 22.00 0.00 bare metal mstatus Write VioletVM 1101 1398 1110.49 1088.49
Figure 20: Cycle-count measurement interval for timer interrupt latency on VioletVM.
shorter context-switch time. Because the Thread-Metric Cooperative Scheduling Test does not directly output the context-switch time, the switch time was estimated using (1), where Ttest is the test duration and Sscore is the score. interrupt latency on bare metal. On bare metal, the The overhead was calculated by subtracting the estimated latency was calculated from the cycle count between the switch time on bare metal from that on VioletVM. Table timer interrupt event and entry to the OS timer interrupt 11 shows the results in the bare-metal and VioletVM enhandler. Figure 20 shows the measurement interval for vironments. timer interrupt latency on VioletVM. On VioletVM, the Ttest endpoint of the same interval was entry to the guest OS Tswitch ≈ (1) Sscore timer interrupt handler, so the measurement includes the interrupt virtualization performed before delivery to the The estimated context-switch time was 0.16 us in the guest OS. The measured cycle count ∆C was converted bare-metal environment and 31.04 us on VioletVM. This to time as ∆C/1.4 GHz using the CPU frequency in this corresponds to an estimated overhead of 30.88 us comevaluation. Table 10 shows the timer interrupt latency in pared with bare metal. the bare-metal and VioletVM environments in us. The functional evaluation showed that on real RISCThe maximum observed timer interrupt latency was V hardware, Violet’s M-mode Emulator can appropriately 0.52 us on bare metal and 1.31 us on VioletVM. Thus, provide an M-mode execution environment, and Linux and the difference between the maximum observed latencies in FreeRTOS can run as guest OSs simultaneously. The perthis measurement was 0.79 us. formance evaluation quantified the overhead introduced by the M-mode Emulator on M-mode CSR accesses, in4.2.3 Thread-Metric Cooperative Scheduling terrupt response, and context switching. This overhead originates from software trap-and-emulate-based M-mode The Thread-Metric Testsuite Cooperative Scheduling Test emulation and is the cost required to run existing M-mode was then executed to evaluate RTOS context-switch perRTOS binaries without modification. formance. In this test, five tasks repeatedly yield the CPU and switch for 30 seconds. The score is the total number of task executions, and a higher score indicates a
11
Emulator, Violet enables the execution of an RTOS in a VM running RISC-V. This allows existing RTOSs to run on a VM in RISC-V and coexist with GPOS such as Linux. Simultaneous execution of FreeRTOS and Linux on actual RISC-V hardware was demonstrated. In addition, RISCV architecture tests showed that the M-mode Emulator can provide an M-mode execution environment consistent Table 11: Thread-Metric cooperative scheduling perfor- with the RISC-V specification. mance. In addition, the performance overhead of the M-mode Est. Est. Emulator was evaluated, and its effects on M-mode CSR Environment Score Switch Time (us) Overhead (us) access, timer interrupt latency, and context switching were Bare-metal 186,968,445 0.16 0.00 quantified. Future work includes considering measures to VioletVM 966,529 31.04 30.88 reduce the overhead introduced by the M-mode Emulator, such as offloading to hardware if necessary. Strict interference isolation through shared hardware resources, 5 Related Work such as shared caches and memory bandwidth, will also Miralis [27] is similar to Violet in that it virtualizes M- be considered when hardware implementing RISC-V QoS mode in RISC-V. Still, its purpose is to protect the OS specifications becomes available, such as the Ssqosid exand enclaves from malicious firmware by running M-mode tension for QoS identifiers and CBQRI for capacity and firmware in a virtualized environment. Therefore, it does bandwidth allocation and monitoring [22, 23]. not mention the co-execution of multiple OSs through the virtualization of RTOS and GPOS. Also, while Violet combines hardware virtualization by the Hypervisor Extension References with software virtualization, Miralis virtualizes M-mode [1] J. Martins, A. Tavares, M. Solieri, M. Bertogna, without using the Hypervisor Extension. and S. Pinto, “Bao: A lightweight static partiBaoHypervisor [21, 28, 29] is a hypervisor aimed at tioning hypervisor for modern multi-core embedded strong isolation between VMs and guaranteeing real-time systems,” in Workshop on Next Generation Realperformance. It is also possible to run FreeRTOS as a Time Embedded Systems (NG-RES 2020), ser. Open guest OS on RISC-V, but it uses a modified version of Access Series in Informatics (OASIcs), M. Bertogna FreeRTOS [30] that can run in S-mode, and full virtualand F. Terraneo, Eds., vol. 77. Dagstuhl, Gerization has not been achieved. many: Schloss Dagstuhl – Leibniz-Zentrum für HSP-V [31] enables the execution of multiple OSs on Informatik, 2020, pp. 3:1–3:14. [Online]. Available: RISC-V by allocating resources to guests through static https://drops.dagstuhl.de/entities/document/10.423 partitioning. It does not perform virtualization and runs 0/OASIcs.NG-RES.2020.3 on RISC-V cores where the Hypervisor Extension is not implemented. Although it mentions running RTOS, since [2] A. Patel, M. Daftedar, M. Shalan, and M. W. ElHSP-V runs in M-mode and executes guest OSs in S-mode, Kharashi, “Embedded hypervisor Xvisor: A comparit is considered to use a modified version of FreeRTOS that ative analysis,” in 2015 23rd Euromicro International runs in S-mode, similar to BaoHypervisor. Conference on Parallel, Distributed, and NetworkRVirt [32] is a hypervisor that enables guest operating Based Processing, 2015, pp. 682–691. systems to run on a virtual machine through trap-andemulate, similar to Violet’s M-mode Emulator. Therefore, [3] H. Li, X. Xu, J. Ren, and Y. Dong, “ACRN: A big little hypervisor for IoT development,” in Proceedings it operates on RISC-V cores that do not implement the of the 15th ACM SIGPLAN/SIGOPS International Hypervisor Extension. However, it does not target MConference on Virtual Execution Environments, ser. mode virtualization for RTOS running. VEE 2019. New York, NY, USA: Association for Xvisor [2] is an embedded hypervisor that supports Computing Machinery, 2019, p. 31–44. many architectures. It supports full virtualization and can run guests without modification. While complex configu[4] D. Reinhardt and G. Morgan, “An embedded hyperrations such as running multiple OSs simultaneously and visor for safety-relevant automotive e/e-systems,” in communicating between them are possible on ARM and Proceedings of the 9th IEEE International Symposium x86 64, it does not mention running RTOS on the RISC-V on Industrial Embedded Systems (SIES 2014), 2014, architecture. pp. 189–198. There are other hypervisors with implementations for RISC-V [18–20], but they target GPOS running in S-mode [5] RISC-V International, “RISC-V annual report and cannot run RTOS running in M-mode. 2025,” RISC-V International, Tech. Rep., Jan. 2025, official annual report. [Online]. Available: https://riscv.org/wp-content/uploads/2026/01/RIS 6 Conclusion C-V-Annual-Report-2025.pdf Table 10: Timer interrupt latency (us). Environment Min Max Avg. Median Bare-metal 0.16 0.52 0.16 0.16 VioletVM 0.66 1.31 1.05 1.03
In this paper, Violet, an embedded hypervisor for RISCV, is proposed. By emulating M-mode with the M-mode
12
[6] FreeRTOS, “FreeRTOS,” https://freertos.org/.
[7] Zephyr Project, “Zephyr project, a Linux foundation project,” https://zephyrproject.org/.
[24] riscv-software-src, “RISCOF,” https://github.com/r iscv-software-src/riscof, Jan. 2023.
[8] R. Yamamoto, “Exploring real-time operating system [25] riscv-non-isa, “RISC-V architecture test SIG,” https: execution strategies on virtual machines in RISC-V //github.com/riscv-non-isa/riscv-arch-test/releases architecture,” https://riscvsummit2024.sched.com/ /tag/3.10.0, Nov. 2024. event/1iYtw/exploring-real-time-operating-syste “RISC-V RV64 SiFive HiFivem-execution-strategies-on-virtual-machines-in-ris [26] petitstrawberry, Premier-P550 GCC,” https://github.com/petitstra c-v-architecture-ryosuke-yamamoto-mitsubishi-ele wberry/FreeRTOS/tree/main/FreeRTOS/Demo/ ctric-corporation, Mitsubishi Electric Corporation, RISC-V RV64 SiFive HiFive-Premier-P550 GCC, 2024. 2023. [9] nekomaru0510, “Violet,” https://github.com/nekom [27] C. Castes, F. Costa, N. S. Kalani, T. Roscoe, N. Fosaru0510/Violet. ter, T. Bourgeat, and E. Bugnion, “The design and [10] sifive, “SiFive HiFive premier P550,” https://www.si implementation of a virtual firmware monitor,” in five.com/boards/hifive-premier-p550. Proceedings of the ACM SIGOPS 31st Symposium on Operating Systems Principles, ser. SOSP ’25. New [11] The RISC-V Instruction Set Manual Volume I: UnYork, NY, USA: Association for Computing Machinprivileged Architecture Version 20240411, May 2024. ery, 2025, p. 85–100. [12] The RISC-V Instruction Set Manual Volume II: Priv[28] B. Sá, L. Valente, J. Martins, D. Rossi, L. Benini, ileged Architecture Version 20240411, May 2024. and S. Pinto, “CVA6 RISC-V virtualization: Archi[13] SiFive, Inc., SiFive Interrupt Cookbook v1.2, 2020. tecture, microarchitecture, and design space exploration,” IEEE Trans. Very Large Scale Integr. Syst., [14] OpenSBI, “OpenSBI,” https://github.com/riscv-sof vol. 31, no. 11, p. 1713–1726, Nov. 2023. tware-src/opensbi. [29] bao-project, “bao-hypervisor,” https://github.com/b ao-project/bao-hypervisor/tree/main.
[15] SiFive, Inc., RISC-V Platform-Level Interrupt Controller Specification, 2023.
[16] RISC-V Foundation: RISC-V Platform Runtime [30] ——, “freertos-over-bao,” https://github.com/bao-p roject/freertos-over-bao. Services Task Group, RISC-V Supervisor Binary Interface Specification Version v2.0, Feb. 2024. [31] J. Sousa, J. Martins, T. Gomes, and S. Pinto, “HSP[Online]. Available: https://github.com/riscv-non-i V: Hypervisor-less static partitioning for RISC-V sa/riscv-sbi-doc/releases/tag/v2.0 COTS platforms,” IEEE Access, vol. 12, pp. 71 131– 71 144, 2024. [17] The Linux Kernel Organization, “Linux,” https://ke rnel.org/. [32] mit-pdos, “RVirt,” https://github.com/mit-pdos/ [18] A. Kivity, Y. Kamay, D. Laor, U. Lublin, and RVirt, 2019. A. Liguori, “KVM: The Linux virtual machine monitor,” in Proceedings of the 2007 Linux Symposium, vol. One, Jun. 2007, pp. 225–230. [19] P. Barham, B. Dragovic, K. Fraser, S. Hand, T. Harris, A. Ho, R. Neugebauer, I. Pratt, and A. Warfield, “Xen and the art of virtualization,” SIGOPS Oper. Syst. Rev., vol. 37, no. 5, p. 164–177, Oct. 2003. [20] M. Dexter, “BSD hypervisor,” https://bhyve.org/. [21] B. Sá, J. Martins, and S. Pinto, “A first look at RISC-V virtualization from an embedded systems perspective,” 2021. [Online]. Available: https://arxiv.org/abs/2103.14951 [22] RISC-V International, RISC-V Quality-of-Service (QoS) Identifiers (Ssqosid) Version v1.0, Jun. 2024, ratified. [Online]. Available: https://docs.riscv.org/r eference/isa/extensions/ssqosid/ attachments/riscv -ssqosid.pdf [23] RISC-V CBQRI Task Group, RISC-V Capacity and Bandwidth QoS Register Interface Version v1.0, Jul. 2024, ratified. [Online]. Available: https://docs.riscv .org/reference/cbqri/ attachments/riscv-cbqri.pdf 13