Speakers
Description
Boot mainline on SpacemiT's Key Stone K3 and half the machine stays dark: eight 1024-bit AI cores rejected by smpboot because riscv_v_vsize allows exactly one vlenb per system. This is not a bring-up bug, it is the first shipping proof that RISC-V vendors will not pay for matched vector widths, and the SG2042's RVV 0.7.1 installed base makes it worse: not narrower, incompatible. Per-process vlenb patches can boot this machine, but no patch changes the physics: 4 KB of vector state cannot land in a 1 KB register file, so any single-kernel fix confines vector tasks to one cluster for life and inherits the arm64 asymmetric-32bit price list: no hotplug of the last capable core, no SCHED_DEADLINE admission, silently rewritten affinity masks, undefined cpuset isolation, plus hwprobe intersecting capabilities down to no vector unit anywhere on a 0.7.1/1.0 mix. The partition was decided at tape-out; the scheduler can only hide it, expensively. We propose making it first class instead: multikernel boots one independent Linux kernel per cluster, each compiled for its exact silicon, seeing a machine where every core matches. The capability word tells the truth, glibc picks real vector routines, hotplug and deadline scheduling and cpusets just work, and RVV 0.7.1 and 1.0 domains coexist on one board. The prototype exists (github.com/multikernel/linux); what it needs is this room. We will present the architecture and the RISC-V gaps we want to close with the community: kernel spawning on the RISC-V boot flow, cross-domain interrupt routing with AIA/IMSIC, and DT/ACPI bindings for heterogeneous vector topology. Heterogeneous VLEN is the RISC-V roadmap, not a corner case. Let's give it a first-class answer before the next SoC tapes out.