Violet: Enabling Full Virtualization for M-mode RTOS on RISC-V

1 Introduction

• RISC-V virtualization targets U-mode and S-mode, not M-mode, leaving RTOSs such as FreeRTOS and Zephyr outside the supported virtualization levels.The paper states that existing M-mode RTOS binaries cannot run unmodified on a VM using only hardware virtualization features.Source: §1 · p. 1
• The paper asks whether Violet can run unmodified M-mode RTOSs, comply with RISC-V, support RTOS–GPOS coexistence on hardware, and what performance cost it incurs.Source: §1 · p. 1
• Violet combines RISC-V virtualization features with software-based M-mode processing emulation to run existing M-mode RTOSs without modification.The paper builds on prior investigation of M-mode RTOS execution and a QEMU hypervisor implementation.Source: §1 · pp. 1–2
• Violet was implemented on actual hardware, demonstrating concurrent execution of FreeRTOS and Linux.Source: §1 · p. 2
• The evaluation quantified emulation overhead for M-mode CSR accesses, interrupt response, and context switching.Source: §1 · p. 2

2.1 Overview of RISC-V

• RISC-V combines a base integer instruction set with optional extensions and restricts instructions, CSRs, and memory access by privilege level.M-mode is most privileged, followed by S-mode and U-mode.Source: §2.1 · p. 2

2.2 Control and Status Registers (CSRs)

• CSRs indicate or control CPU state, and their accessibility depends on privilege level; M-mode registers include supervisor-register fields, but not vice versa.For example, mstatus, mie, and mip are supersets of sstatus, sie, and sip.Source: §2.2 · p. 2

2.3 Interrupt Controllers

• CLINT manages software and timer interrupts, while PLIC manages external interrupts and supports interrupt distribution across cores.CLINT is commonly managed by M-mode firmware; PLIC registers configure interrupt enablement, priorities, and pending status.Source: §2.3 · p. 2

2.4 Supervisor Binary Interface (SBI)

• The SBI abstracts platform-specific functionality, letting an OS request hardware services such as interrupt and timer operations from M-mode firmware.This provides a hardware-independent interface between the OS and firmware.Source: §2.4 · p. 2

2.5 Execution Privilege Levels of GPOS and RTOS

• A GPOS typically runs in S-mode, with firmware in M-mode and applications in U-mode; RTOSs such as FreeRTOS and Zephyr run in M-mode and directly access hardware.RTOSs typically do not use SBI.Source: §2.5 · p. 3

2.6 Hardware Virtualization Support: Hypervisor Extension

• The Hypervisor Extension adds hypervisor and VM privilege levels, CSRs, and instructions; guest OS SBI requests are virtualized when required.Guest OSs use SBI to configure timers and control interrupts between cores.Source: §2.6 · p. 3

2.6.1 HS-mode

• HS-mode is the hypervisor privilege level that replaces S-mode, with added CSR and hypervisor instructions, and includes registers for VM state and two-stage address translation.The translation supports memory isolation between guest OSs and between guests and the hypervisor.Source: §2.6.1 · p. 3

2.7 Challenge in Executing M-mode RTOS

• The Hypervisor Extension virtualizes S-mode and U-mode, but not M-mode, so existing RISC-V hypervisors cannot run M-mode RTOSs as guests or alongside a GPOS.The extension therefore lacks virtualization for M-mode registers and privileged instructions.Source: §2.7 · p. 3, Figure 3 · p. 4

3.1 Overview

• M-mode RTOSs run as VS-mode guests by combining the Hypervisor Extension with the M-mode Emulator.S-mode GPOSs instead use the Hypervisor Extension’s virtualization support features.Source: §3.1 · p. 4
• Violet can co-execute a GPOS and RTOS or run multiple RTOSs.Each guest OS runs independently.Source: §3.1 · p. 4
• Violet provides unmodified guest OSs with a virtualized hardware environment in VS-mode.It combines the Hypervisor Extension with software-based M-mode processing emulation for RTOS guests.Source: §3.1 · p. 4
• Guest OSs directly access assigned devices through pass-through mode, minimizing virtualization overhead.Violet uses pass-through except for specific devices.Source: §3.1 · p. 4

3.2 Execution of GPOS

• S-mode GPOSs run in VS-mode, with applications in VU-mode, using two-stage address translation for memory access.S-mode privileged instructions and CSR accesses are hardware-translated, so CPU-feature virtualization by software is unnecessary.Source: §3.2 · p. 4

3.2.1 SBI Virtualization

• Violet implements SBI, virtualizes guest requests, and forwards them to OpenSBI when necessary.This makes the guest GPOS perceive SBI firmware as running in M-mode.Source: §3.2.1 · p. 4

3.2.2 Device Pass-through

• Static MMIO mappings let guests directly access assigned devices, but shared-cache and memory-bandwidth interference is not controlled.Strict interference isolation is outside scope because hardware implementing the cited RISC-V QoS specifications is unavailable.Source: §3.2.2 · pp. 4–5

3.2.3 PLIC Virtualization

• Violet uses a Virtual PLIC because the physical PLIC cannot notify VS-mode guests and direct access could expose inconsistent state.Interrupts intended for S-mode must otherwise be trapped and converted for VS-mode notification.Source: §3.2.3 · p. 5

3.3 Execution of RTOS

• Violet combines the Hypervisor Extension with an M-mode Emulator to run unmodified M-mode RTOSs on a VM.The RTOS operates within the emulation environment.Source: §3.3 · p. 5

3.4 M-mode Emulator

• The M-mode Emulator supplies an M-mode execution environment by emulating privileged instructions, CSR accesses, interrupts, and exceptions in software.The guest runs in VS-mode, where M-mode instructions and CSRs cannot be accessed directly.Source: §3.4 · p. 5

3.4.1 Emulation of Privileged Instructions

• ECALL and MRET are trapped in VS-mode and emulated to reproduce M-mode behavior, including guest trap handling and return state.For MRET, Violet restores the virtualized return destination and interrupt state, then resumes the guest using SRET.Source: §3.4.1 · pp. 5–6, Figure 6 · p. 6

3.4.2 Emulation of CSR accesses

• CSRs inaccessible from VS-mode are handled through virtual CSRs or emulated accesses, with register-specific behavior.Violet traps illegal CSR accesses, decodes the register and access type, then emulates it or maps it to a VS-mode CSR.Source: §3.4.2 · p. 6, (c) Read-only CSRs · p. 6

(a) CSRs replaceable with VS-mode CSRs

• CSRs with equivalent VS-mode counterparts can be mapped to them, with value conversion where register fields differ.For example, mstatus and mcause require conversion on reads and writes; mtvec can map to vstvec.Source: (a) CSRs replaceable with VS-mode CSRs · p. 6, Figure 8 · p. 6

(b) PMP-related CSRs

• Because PMP-related CSRs cannot be accessed from VS-mode or S-mode, Violet emulates both their accesses and PMP memory protection.Violet cannot use PMP for protection while operating in HS-mode, so it emulates that protection using paging.Source: (b) PMP-related CSRs · p. 6

(c) Read-only CSRs

• For read-only CSRs, Violet returns arbitrary values and implements selected registers as virtual registers.The listed virtual registers include mhartid, mstatus, mie, mip, mcause, mepc, mtvec, mideleg, medeleg, mtval, mscratch, and misa.Source: (c) Read-only CSRs · p. 6, Figure 7 · p. 6

3.4.3 Interrupt and Exception Emulation

• Violet converts M-mode interrupts and exceptions to VS-mode events and maps interrupt-related CSR fields so the guest can handle them as M-mode events.It traps accesses to mstatus, mie, and mcause; interrupt injection updates VCLINT or VPLIC state and sets the corresponding VS-mode pending state.Source: §3.4.3 · pp. 6–7

3.4.4 CLINT Emulation

• Violet provides VCLINT because M-mode firmware may restrict guest access to the physical CLINT.VCLINT implements mtime and mtimecmp, and uses SBI to set the physical timer when its registers are manipulated.Source: §3.4.4 · pp. 7–8

4 Evaluation

• The evaluation used RISCOF and riscv-arch-test for specification-related testing, then assessed FreeRTOS execution, mixed-OS execution, and performance overhead.The architecture tests configured VioletVM as an M-mode-only implementation on the HiFive Premier P550.Source: §4 · p. 8, §4.1.1 · p. 8

4.1.1 Architecture-Test-Based Evaluation of the M-mode Emulator

• 664 of 674 RISCOF tests passed; the 10 failures concerned misaligned accesses or breakpoint instructions, outside the functional evaluation scope or ignorable.The authors report that the remaining tests passed and confirm expected M-mode behavior within the riscv-arch-test coverage.Source: §4.1.1 · p. 9, Table 7 · p. 9

4.1.2 Evaluation of FreeRTOS Execution

• FreeRTOS ran its sample program on Violet, producing periodic UART messages via timer interrupts and demonstrating basic VM, trap, and emulation functions.The configuration virtualized CLINT while passing through other devices such as UART.Source: §4.1.2 · p. 9, Figure 14 · p. 9, Figure 15 · p. 10

4.1.3 Evaluation of Concurrent Execution of Linux and FreeRTOS

• Linux and FreeRTOS ran simultaneously on separate Violet VMs, with UART0 shared only for log output.Linux ran on VM0 and FreeRTOS on VM1; the mixed log reflects the shared UART0.Source: §4.1.3 · p. 10, Figure 16 · p. 10

4.2.1 M-mode CSR Access Latency

• 1088 to 1658 cycles of additional overhead were measured for representative M-mode CSR accesses versus the M-mode bare-metal baseline.The reported representative CSR access overhead results from Violet trapping guest accesses and processing them in software.Source: §4.2.1 · p. 10, Table 9 · p. 11

4.2.2 Timer Interrupt Latency

• 0.79 us was the difference between maximum observed timer interrupt latencies: 0.52 us on bare metal and 1.31 us on VioletVM.The VioletVM interval includes interrupt virtualization before delivery to the guest OS.Source: §4.2.2 · p. 11, Table 10 · p. 12

4.2.3 Thread-Metric Cooperative Scheduling

• 30.88 us of estimated context-switch overhead separated VioletVM’s 31.04 us from bare metal’s 0.16 us.The estimates came from the Thread-Metric Cooperative Scheduling Test, where five tasks repeatedly yielded the CPU for 30 seconds.Source: §4.2.3 · p. 11, Table 11 · p. 12

4.2 Evaluation of Performance Overhead

• Violet’s M-mode emulation adds overhead to CSR accesses, interrupt response, and context switching compared with bare metal.The paper attributes this overhead to software trap-and-emulate processing required to run unmodified M-mode RTOS binaries.Source: §4.2.3 · p. 11

5 Related Work

• Miralis virtualizes M-mode to protect the OS and enclaves from malicious firmware, rather than discussing co-execution of RTOS and GPOS guests.Unlike Violet, Miralis does not use the Hypervisor Extension for M-mode virtualization.Source: §5 · p. 12
• BaoHypervisor can run FreeRTOS as a guest using a modified S-mode version, but the paper describes this as not achieving full virtualization.Source: §5 · p. 12
• HSP-V statically partitions resources without virtualization and is described as using a modified S-mode FreeRTOS guest.HSP-V runs in M-mode and executes guest operating systems in S-mode.Source: §5 · p. 12
• RVirt uses trap-and-emulate on RISC-V cores without the Hypervisor Extension, but does not target M-mode RTOS virtualization.Source: §5 · p. 12
• Xvisor supports full virtualization and unmodified guests on ARM and x86-64, but its RISC-V discussion does not mention RTOS execution.Other cited RISC-V hypervisors target S-mode GPOSs and cannot run M-mode RTOSs.Source: §5 · p. 12

• Violet emulates M-mode to enable RTOS execution in a RISC-V VM.The paper proposes Violet as an embedded hypervisor using an M-mode Emulator.Source: §6 · p. 12
• FreeRTOS and Linux ran simultaneously on real RISC-V hardware, while architecture tests showed the emulator provides an M-mode environment consistent with the specification.Source: §6 · p. 12
• The evaluation quantified overhead for M-mode CSR accesses, timer interrupt latency, and context switching; future work considers hardware offloading and QoS-based interference isolation.Source: §6 · p. 12