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.

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.

Why RISC-V?

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 a hypervisor-extended supervisor mode.

RISC-V specifications describe the current virtualization mode using the symbol V.  If  V=1 then the system is currently in guest context, otherwise it is in host context (either supervisor or user mode).

The RISC-V H extension introduces a full duplicate of CPU state: one copy for the guest and one copy for the host.  While V=1, attempts to access privileged CPU state or execute privileged 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 hypervisor-extended supervisor mode (V=0) privileged.

This tried and true scheme results in behavior such as firmware calls (ecall) trapping to the hypervisor for emulation, manipulation of supervisor page tables only affecting the guest, or access to device MMIO address ranges trapping to the hypervisor and being emulated behind the scenes.  When a guest configures its own sstatus state, it's really configuring a "virtual" copy of that register that is only active whileV=1.  When V=0 that register is inactive.

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 stage-one 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 stage-two of address translation for guests.

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 largely 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.  Timer and software interrupts are emulated along with the rest of the SBI implementation, as timer and software interrupts are issued across the SBI boundary.

Future

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 leverages the virtualization capabilities of the ISA.

Stay tuned!