RISC-V CPU & System software implementation written in С
- Passes RISC-V compliance/torture tests for both RV64 & RV32
- OpenSBI, U-Boot, custom firmwares boot and execute properly
- Working Linux, FreeBSD, OpenBSD & other cool guest OSes
- Haiku OS guest support (WIP)
- Tracing JIT, multicore support
- Framebuffer graphics, mouse & keyboard, UART shell
- NVMe storage drives
- Networking (WIP)
- Feature-complete RV64IMAFDC instruction set
- Multicore support (SMP), SV32/SV39/SV48/SV57 MMU
- Tracing RVJIT with x86_64, ARM64, RISC-V, i386, ARM backends (faster than QEMU, yay!)
- Bootrom, Kernel Image loading
- Device Tree auto-generation, passing to firmware/kernel
- RVVM Public API for VM integration
- UART 16550a-compatible text console
- PLIC/ACLINT, Timers, Poweroff/reset
- Generic PCI Express Bus
- NVMe storage, image TRIM support, fast IO
- Graphical framebuffer through X11/WinAPI/Haiku/SDL
- I2C HID (keyboard/mouse), OpenCores I2C controller
- OpenCores Ethernet through Linux TAP / WIP usernet
- PS2 Altera (keyboard/mouse), deprecated
- ATA hard drive (PIO / IDE PCI), deprecated
Currently builds using GNU Make (recommended) or CMake and is extremely portable.
git clone https://github.com/LekKit/RVVM
cd RVVM
make
cd release.linux.x86_64
./rvvm_x86_64 -h
You can configure the build with USE flags. To cross-compile, pass CC=target-gcc to make. If it fails to detect features, pass ARCH/OS variables explicitly.
Examples:
make lib CC=aarch64-linux-android21-clang USE_FB=0
make lib all CC=x86_64-w64-mingw32-gcc USE_NET=1
make CFLAGS=-m32 ARCH=i386 USE_RV64=0 BUILDDIR=build BINARY=rvvm
make CC=mipseb-linux-gnu-gcc USE_JIT=0
Alternatively, you can use CMake:
git clone https://github.com/LekKit/RVVM
cd RVVM
mkdir build
cmake -S. -Bbuild
cmake --build build --target all
cd build
./rvvm -h
./rvvm fw_jump.bin -k u-boot_s.bin -i drive.img -m 2G -smp 2 -res 1280x720 -jitcache 64M
Argument explanation:
[fw_jump.bin] Initial M-mode firmware, OpenSBI in this case
-k, -kernel u-boot.bin S-mode kernel payload (Linux Image, U-Boot, etc)
-i, -image drive.img Attach NVMe storage image (Raw format as of now)
-m, -mem 2G Memory amount (may be suffixed by k/M/G), default 256M
-s, -smp 2 Amount of cores, single-core machine by default
-res 1280x720 Changes framebuffer & VM window resolution
-jitcache 64M Raise JIT cache limit (64M recommended for complex guests)
. . .
-rv32 Enable 32-bit RISC-V, 64-bit by default
-cmdline, -append ... Override/append default kernel command line
-nogui, -nojit Disable GUI (Use only UART), Disable JIT (for debugging)
Invoke "./rvvm -h" to see extended help.
OS | JIT | GUI |
---|---|---|
Linux | Works | X11, SDL |
Windows | Works | Win32, SDL |
MacOS X | Works, need signing for M1 | SDL, XQuartz |
FreeBSD | Works | X11, SDL |
Haiku OS | Works | Haiku, SDL |
Serenity | Broken due to W^X safety | SDL |
Windows CE | Broken | Win32 |
Emscripten | - | SDL |
Achievments | Working on | |
---|---|---|
LekKit | RVVM API & codebase infrastructure RV64IMAFDC interpreter, IRQ/MMU/Priv RVJIT Compiler, X86/RISC-V backends NVMe, ACLINT, UART, I2C, graphics Rework of PCIe, Ethernet, PS/2 |
Networking, Userspace emulation |
cerg2010cerg2010 | Important fixes, initial RV64 work PLIC, PCI bus, PS2 HID, ATA, Ethernet OC ARM/ARM64 RVJIT backends |
Testing, Assistance |
Mr0maks | Initial C/M ext interpreter, VM debugger, CSR work, basic UART ARM32 mul/div JIT intrinsics |
- |
0xCatPKG | Userspace network, new argument parser Extended testing & portability fixes |
HD Audio |
X547 | Haiku GUI, I2C HID, Userland API assistance | Guest Haiku support, UserlandVM |
- Stable TCP buffering, a better NIC
- Suspend/resume to file, VM migration
- Sparse block image format, compression/deduplication
- Sound (HD Audio or else)
- Linux userspace syscalls emulation, ELF loader
- VFIO for GPU passthrough
- More RVJIT optimizations, shared caches
- FPU JIT, Vector/Bitmanip extensions (Waiting for GCC V ext support)
- Other peripherals from real boards (SiFive GPIO, flash)
- Maybe virtio devices (Don't like the idea of fictional devices)
- A lot more...
- KVM hypervisor? Alternative CPU engines?