Hypervisor — Rumkv
ARM64 EL2 Complete
Rumkv is the Nexus Type-1 hypervisor. It operates at the highest hardware privilege level, providing hardware isolation between the Rumpk kernel and any guest operating systems.
Architecture
Rumkv is a thin hypervisor — its job is isolation, not emulation:
| Platform | Privilege Level | Role |
|---|---|---|
| ARM64 | EL2 | Hypervisor |
| x86_64 | Ring -1 (VMX root) | Hypervisor |
| RISC-V | M-Mode | Hypervisor |
The Rumpk kernel runs one level below (EL1 / Ring 0 / S-Mode). Applications run at the lowest level (EL0 / Ring 3 / U-Mode).
What Rumkv Provides
- Memory isolation: Stage-2 page tables prevent guests from accessing each other's memory or the hypervisor's memory
- Interrupt virtualization: Hardware interrupts are routed to the correct guest via virtual interrupt injection
- Timer virtualization: Each guest gets its own virtual timer
- Device passthrough: VirtIO devices can be assigned to specific guests
What Rumkv Does NOT Do
Rumkv is not a full virtualization platform like KVM or Xen. It does not:
- Emulate x86 on ARM or vice versa
- Provide virtual network switches between guests
- Run multiple general-purpose operating systems side by side (that's what NexBox + containerd is for)
Its primary purpose is to provide a hardware root of trust and isolation boundary below the Rumpk kernel.
Verified Guest Support
Rumkv has been verified with:
- NetBSD 10.1 (ARM64 guest) — boots and runs userland
- Rumpk (primary guest) — the standard deployment model
Core Topology
The hypervisor manages a core topology that maps physical CPU cores to virtual processors:
- Each physical core can host exactly one Rumpk instance (the common case)
- In multi-guest mode, cores are statically partitioned between guests
- No time-sharing of cores between guests — this is deliberate to maintain determinism
Integration with Rumpk
In the standard deployment, Rumkv is transparent:
- nexus-boot loads Rumkv at the highest privilege level
- Rumkv sets up Stage-2 page tables and virtual interrupts
- Rumkv loads and boots Rumpk at the next privilege level
- Rumpk sees a clean hardware interface — it does not know (or care) that a hypervisor exists below it
The SysTable ABI is the same whether Rumkv is present or not. NPLs and NPKs see no difference.