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.
What is RISC-V?
Here is the intro from the Wikipedia article:
RISC-V (pronounced "risk-five") is an open standard instruction set architecture (ISA) based on established reduced instruction set computer (RISC) principles. Unlike most other ISA designs, the RISC-V ISA is provided under open source licenses that do not require fees to use.
You can take also a look at the RISC-V International website, the non-profit organization supporting the project.
RISC-V offers an opportunity for hardware designers to design simpler chips with a royalty-free ISA. This simplicity makes RISC-V chips potentially enormous competitors in high security application processors, as the reduced cost and complexity makes higher levels of verification a possibility and with that comes higher levels of trust in the processor.
There is a lot to be done on the hardware side of the RISC-V ecosystem, but it also needs the software ecosystem to be mature enough for large scale adoption. This is the arena in which we'd like to contribute. In return, Xen will be able to operate on this new class of processors and reap the rewards offered by the hardware as it rolls out.
Just imagine the level of power and trust offered by a fully Open Source stack: from the CPU, to the virtualization platform with XCP-ng, the management/backup with Xen Orchestra and finally your applications/services on the top!
How does it support virtualization?
Virtualization of CPUs
RISC-V supports the virtualization of CPUs by making sensitive registers and instructions privileged to host mode.
RISC-V describes the current virtualization mode using the symbol
V=1 then the system is currently in guest context, otherwise it is in host context.
The RISC-V H extension introduces a full duplicate of CPU state: one copy for the guest and one copy for the host (similar to Intel VT-x). While
V=1, all CPU state and instructions typically restricted to privileged mode either a) cause a trap, or b) only affect the guest copy of the CPU state. All sensitive instructions become host mode (
This tried and true scheme results in behavior such as firmware calls (
ecall) trapping to the hypervisor for emulation or means that firmware calls (
ecall , similar to calls to the SMI handler),
How does RISC-V support CPU virtualization?
RISC-V supports the virtualization of CPUs by offering trap configuration for privileged system register accesses.
Virtualization of Memory
How does RISC-V support virtualization of memory? This answer is very short: multi-stage page tables (just like other architectures).
In RISC-V, the root of the page tables is the register
satp which points to
V=0 mode tables and
vsatp which points to
V=1 mode tables for supervisor privilege modes. The hypervisor updates the second stage tables by updating the tables found at the address in
hgatp, which are responsible for performing the second stage of address translation.
The RISC-V designers decided to make it easy on the software people and implement identical page table entry formats for both guest and host tables, which adds a nice touch.
Virtualization of I/O
I/O virtualization is left to be specified and will mostly be a feature of the IOMMU and the Platform-Level Interrupt Controller (PLIC), which lies outside the domain of the ISA to specify. The PLIC, as specified right now, does not yet include registers for configuring injection of interrupts. This requires hypervisors to use a trap-and-emulate technique with significant overhead. When the hardware is advanced, these extraneous traps will be eliminated.
As we continue the effort of porting Xen to RISC-V, we will make periodic posts about different aspects of the RISC-V ISA and the Xen port, and particularly about how the Xen port will be leverage the ISA to take full advantage of the hardware.