Contrats Priit Trees on having ARM Mali GPU working on a Rockchip RK3399 board!

Priit extracted required bits from the CheriBSD repository, such as Panfrost GPU kernel driver, kernel drm, libdrm and mesa3d. Then applied everything to the latest FreeBSD and has got Wayfire 3D desktop working!

Panfrost is the first ever GPU kernel driver available for FreeBSD/arm64. I wrote it a few years ago for the CheriBSD as part of ARM/Cambridge "Morello" program.

Initially targeting Rockchip platforms, Panfrost is now enabled by default on the ARM Morello desktop with the real (not FPGA) capability-enabled CHERI CPU.
See https://www.arm.com/architecture/cpu/morello
and https://www.cheribsd.org/.

bhyve for RISC-V source code is now available:
1. kernel part: https://reviews.freebsd.org/D45553
2. userspace part: https://reviews.freebsd.org/D45512

I've started a wiki page providing the project status and list of TODOs: https://wiki.freebsd.org/riscv/bhyve

If someone can test this -- let me know!

I think Hypervisor for RISC-V mostly works!

In the last couple of weeks I was working on SMP support for it.
The task divided into two parts: SMP in the host system (qemu) support and SMP in the guest system support.

I did SMP support for the FreeBSD/RISC-V project and MDEPX RTOS years ago. SiFive has provided to me one of the first SMP boards (Hifive Unleashed), which resulted into a commit https://github.com/freebsd/freebsd-src/commit/b803d0b79079582f84de71f78d4d13e26210171f

So not something new to me, but hypervisor environment adds some complexity which took me away from real life for a while.

Overall, it was all about writing emulation code for the SBI IPI and SBI HSM extensions, protecting APLIC structures from concurrent access and managing interrupt bits in control status registers (CSRs).

The HSM extension is similar to ARM PSCI -- it allows to manage power of secondary processors using SBI requests to firmware. Previously (before HSM), RISC-V was just throwing all the cores into the entry point of FreeBSD at the same time on startup. A core that arrives first makes the boot process. Now we are making SBI request to enable the core when it is actually needed during MP startup.

SBI IPI extension emulation code simply set Supervisor Software interrupt pending bits in the local interrupt controllers of particular CPUs by request from FreeBSD. The SBI IPI extension support in FreeBSD done by my stunning colleague Jessica: https://github.com/freebsd/freebsd-src/blob/main/sys/riscv/riscv/sbi_ipi.c

RISC-V uses relaxed memory concurrency model which means loads of stores on a CPU could be seen in different order on another CPUs. We would need to provide support for remote fences, i.e. issuing a fence instruction on secondary CPUs by request from FreeBSD. In RISC-V it is provided by SBI RFNC extension. I did not write emulation code for this yet as it is needed on real hardware mostly.

Overall I've spent around 3 full months to get to this point, and here is a boot log of 8-core FreeBSD guest system running in 8-core QEMU under x86 host:
https://people.freebsd.org/~br/freebsd_riscv_hypervisor_smp.txt

Now, we are waiting for the real hardware with hypervisor spec included, so we can push FreeBSD boards with hypervisor spec everywhere!

Lets talk about virtual memory! During last week I was working on second stage address translation support for the Bhyve project on FreeBSD/RISC-V.
The first stage (guest-virtual to guest-physical) is used by the guest VM and requires no change, while the second stage (guest-physical to host-physical) is managed by the host and has some modifications.
So the RISC-V hypervisor spec introduces new address translation schemes for the 2nd stage: sv32x4, sv39x4, sv48x4 and sv57x4. These schemes as similar to traditional sv32, sv39, etc except the top directory page. So the top page is expanded by a factor of four to be a 16K page (instead of usual 4K).
This changes the partitioning of incoming virtual address, so that the high end virtual page number (VPN) is now 11 bits, instead of usual 9. This means that the top page accommodates 2048 page table entries now (instead of 512). This technique quadruples amount of virtual memory each traditional scheme provides.

I did several approaches to support new schemes in our sys/riscv/riscv/pmap.c. [NB. Pmap is the machine-dependent part of the most sensitive freebsd subsystem -- virtual memory]. But after some time I realized that there is little to no sense to complicate our pmap.c and to support so much memory. For example, Sv48x4 could give us 1 petabyte of memory. Most importantly, our VM space layout does not allow to support all that memory as the user VA space is currently limited to 128TB.

In result, we have introduced these changes:
1) split the pmap operation into stage1/stage2 for the host and hypervisor.
2) manage the top directory page for stage2, which is now bigger.
3) leave extra space in the top directory unused.

Thanks Mitchell for review and cooperation:
https://github.com/freebsd/freebsd-src/commit/03b330e1916f468b16f7dbd0b7bd67b567a1eb1e

GitHub

riscv: add stage 2 translation to pmap. · freebsd/freebsd-src@03b330e

Add basic stage 2 translation support (guest-physical to host-physical). RISC-V hypervisor spec[1] introduces new translation schemes: Sv32x4, Sv39x4, Sv48x4 and Sv57x4. In each case, the size of ...

Finished design for a test board: 8 layers PCB, 5x5cm.

Never soldered down BGA packages by hand before, so I placed a small copper rectangle on each corner of BGA packages. Hopefully, this should help to align packages properly during placement.
The white silkscreen layer outlines all the components, but it usually comes with offset so can't really be used for aligning fine-pitch packages.

I also spent a day to emulate MMIO bus for the UART adapter. A bit funny but we are using emulation of ARM PL011 serial adapter on RISC-V. It is in polling mode due to no APLIC support at this moment.For MMIO we would need a callback for each read/write to a device memory map. We could not just make a mapping in the process address space where VM is running as we will not receive any callback in userspace. Instead we have to leave the guest system for every read/write and serve the request outside (in the user or kernel mode) then to enter the guest again. Unlike arm64 VHE, the RISC-V H spec does not provide detail information on the instruction that caused a trap, so I had to decode trapping instructions to figure out access width, type of access (read/write) and the length of instruction. All of that is needed for MMIO emulation. RISC-V instructions are 4 bytes, but I have compressed ISA enabled so some of instructions are just 2 bytes in length. We would need to know the address of the next instruction before we return back to the guest. Here I violate the 'small steps' rule, but I was lazy to recompile entire world with compressed-ISA disabled.

My next goal is emulate AIA APLIC -- Stay tuned!

Here we are: https://people.freebsd.org/~br/freebsd_riscv_hypervisor.txt --RISC-V guest booted up!

It took exactly 26 days since I opened the spec, which is a fraction of time that was required compare to the similar work on arm64. To be fair arm64 is a much more complex architecture.
What I noticed in arm64's vmm code, a part of kernel VMM code is running in the hypervisor privilege level EL2 itself. So when we are entering guest into EL2, we are switching into EL2 vmm's code first, then preparing guest and then entering guest. This is how ARM VHE is designed -- you have to enter EL2 to manage EL1 contexts (whether it's the host kernel or guest) . Same for traps/exceptions: they are handled in EL2 first. In RISC-V we are just leaving the host system using 'sret' instruction and immediately appear in VS/VU modes. No management code is running in VS/VU modes.

So the approach on riscv64 is to split the work into small steps, i.e. not to deal with multiple kernel areas at the same time.

The first step is to modify the ISA, so that the first and second stage of translation could be served by a proven hardware-software mechanism of address translation. In that case we can ignore work on pmap.c, which is the machine-dependent part of virtual memory subsystem. VM is the most sensitive subsystem of FreeBSD, dealing with it is better when everything else is working. I simply removed the extra two bits widening of root page table directory (2nd stage of translation) from Spike simulator. We can deal with this some time later.

The same approach was in 2015 when I was porting FreeBSD to RISC-V. I have modified the ISA adding one more page table base register to ensure that the system uses a pointer to page directory (for page table walking) depending on the current privilege level. This makes life easier when you take a trap you don't need to switch page table directories before the next instruction fetch (which could be tricky as the privilege level has changed.) Note that arm64 has a page table base register per each privilege level, while RISC-V has just one for entire system.

Second is to emulate minimum subsystems and use hardware virtualization at maximum. I found the new RISC-V SSTC extension that is providing vstimecmp register (virtualized stimecmp -- time comparator) allowing us to schedule a timer interrupt from the guest system. vstimecmp uses architectural core-local interrupt controller which is working in guest environment as well.
Unfortunately, there is no virtualization support in the platform-level interrupt-controller PLIC, including the new AIA APLIC from Advanced Interrupt Controller spec. We will have to fully emulate it in the vmm code.
The APLIC is not needed right now as it provide interrupts for devices on MMIO bus, we don't have any devices apart from serial adapter for now. Even the serial adapter is optional as we could rely on legacy SBI console.

Requests for current time and cycle count are currently passed to the host, wait-for-interrupt (WFI) call ignored. Root file system image reduced to a size of 8mb and packed into the kernel, so that no storage devices needed for FreeBSD. I am using 'bootrom' feature of bhyve(8) that is basically taking the kernel binary and puts it into the guest address space. Ideally we would use a path to the U-Boot binary, but we are taking small steps.

I had to emulate SBI in the host kernel as RISC-V hypervisor spec provides no virtual machine mode. The SBI requests that are coming from FreeBSD are requesting service for power management, information about the system, RISC-V extensions supported, etc.

Managed to drive a display embedded into a cover of my old smartphone. 4 lane MIPI DSI, frequency 500 MHz (video mode).

We may notice low frame rate, but that is vt(9) redraw rate of 25 Hz, not the DSI which is much faster.

We can hack the touch support as well but first want to pick the right display for the project. Another two panels to go!