Tracking issue for porting multikernel to RISC-V. Companion to the arm64 tracking issue #21; the generic-core cleanups in #8 are a shared prerequisite.
Evaluation summary
RISC-V is the easiest of the three architectures on the CPU side. S-mode kernels never own the hart lifecycle; SBI HSM does, and Linux already drives hotplug through it (cpu_ops_sbi.c). HART_START(hartid, addr, opaque) enters with satp = 0, interrupts masked, a0 = hartid, a1 = opaque, which is exactly the Linux boot protocol (a0 = hartid, a1 = DTB). So:
- pool = HSM STOPPED state, a parked hart executes nothing;
- primary boot trampoline = one HART_START ecall;
- spawn secondaries use stock sbi_cpu_start() / sbi_cpu_stop();
- confirm-parked = HART_STATUS == STOPPED;
- no inherited CPU state, no identity page tables, no repark bookkeeping.
Two sharp edges arm64 does not have:
- Stale I-cache on re-spawn: no remote I-cache invalidation, _start_kernel does not fence.i in S-mode, OpenSBI does not invalidate on HART_START. Fix: a constant fence.i; jr entry stub in the ctrl block, the only multikernel assembly RISC-V needs.
- SRST resets the whole machine: a spawn running stock machine_halt()/reboot powers off the host. The HART_STOP-everywhere override is a prerequisite for the first spawn that reaches userspace.
Interrupts partition by source (PLIC contexts, APLIC sourcecfg/target). IMSIC has one interrupt file per hart, so MSI is a direct write and the spawn composes MSI messages itself: the arm64 host-proxied ITS (#16) has no RISC-V counterpart. What RISC-V lacks is a forced-halt primitive: no S-mode NMI, and SBI SSE (the fix) is not in the tree yet.
Full write-up: /tmp/multikernel-riscv-design.md (includes an x86 / arm64 / RISC-V comparison table).
Tasks, in dependency order
Foundation
CPU lifecycle (small, low risk; #23, #24, #25 land together)
Boot data and messaging
Milestone A: device-less spawn boots on its own harts and memory with earlycon=sbi, exchanges ring messages, halts gracefully, survives a 50x re-spawn loop.
Interrupts (pick by target platform)
Milestone B: an assigned PCIe device with MSI works in a spawn (QEMU aia=aplic-imsic first).
Robustness and isolation
Optional
Infrastructure
Targets: QEMU virt with OpenSBI (aia=none and aia=aplic-imsic), then SG2042 (Milk-V Pioneer, 64 harts, PLIC, PCIe).
Tracking issue for porting multikernel to RISC-V. Companion to the arm64 tracking issue #21; the generic-core cleanups in #8 are a shared prerequisite.
Evaluation summary
RISC-V is the easiest of the three architectures on the CPU side. S-mode kernels never own the hart lifecycle; SBI HSM does, and Linux already drives hotplug through it (cpu_ops_sbi.c). HART_START(hartid, addr, opaque) enters with satp = 0, interrupts masked, a0 = hartid, a1 = opaque, which is exactly the Linux boot protocol (a0 = hartid, a1 = DTB). So:
Two sharp edges arm64 does not have:
Interrupts partition by source (PLIC contexts, APLIC sourcecfg/target). IMSIC has one interrupt file per hart, so MSI is a direct write and the spawn composes MSI messages itself: the arm64 host-proxied ITS (#16) has no RISC-V counterpart. What RISC-V lacks is a forced-halt primitive: no S-mode NMI, and SBI SSE (the fix) is not in the tree yet.
Full write-up: /tmp/multikernel-riscv-design.md (includes an x86 / arm64 / RISC-V comparison table).
Tasks, in dependency order
Foundation
CPU lifecycle (small, low risk; #23, #24, #25 land together)
Boot data and messaging
Milestone A: device-less spawn boots on its own harts and memory with earlycon=sbi, exchanges ring messages, halts gracefully, survives a 50x re-spawn loop.
Interrupts (pick by target platform)
Milestone B: an assigned PCIe device with MSI works in a spawn (QEMU aia=aplic-imsic first).
Robustness and isolation
Optional
Infrastructure
Targets: QEMU virt with OpenSBI (aia=none and aia=aplic-imsic), then SG2042 (Milk-V Pioneer, 64 harts, PLIC, PCIe).