One Kernel Per Cluster, Every Core at Full Capability
RISC-V server silicon now ships clusters with different vector widths on the same die: 256-bit general-purpose cores next to 1024-bit AI cores. A single kernel either refuses half the machine or degrades all of it. Multikernel aligns the software boundary with the silicon: one Linux kernel per cluster, each compiled for its exact hardware, each running at full width.
The Partition Is Not Optional
A wide vector unit is the most expensive block in a modern core, so vendors deploy it only on the clusters that need it. Heterogeneous vector width is a deliberate product decision, not a defect. The machine will be partitioned in either case; the choice is between a designed boundary and an incidental one inside the scheduler.
The Silicon Splits
Shipping parts pair 256-bit and 1024-bit vector clusters on one die, a four-fold width gap. The installed base is harder still: draft RVV 0.7.1 silicon is instruction-level incompatible with ratified RVV 1.0.
A Single Kernel Refuses
Mainline Linux inspects each core as it comes up, sees a vector width that does not match the boot core, and never brings it online. The flagship cluster, the chip's defining feature, never comes online.
A Patched Kernel Degrades
Per-process width patches hide the partition instead of removing it: hotplug restrictions, deadline scheduling refused, affinity silently overridden, and a kernel binary compiled for the narrowest cluster. The general-purpose cores absorb the cost of an AI cluster they never use.
Draw the Boundary Where the Silicon Drew It
Multikernel boots one independent Linux kernel per cluster. Inside each domain, Linux behaves like Linux on an ordinary machine, because from that kernel's point of view, it is one.
Same die, two vector widths. Each kernel records the width its cores really have, so every cluster runs at full capability on day one.
Every Kernel Sees Matched Cores
The reported hardware capabilities (hwcap) describe the silicon programs actually run on, and the C library selects the vector routines the hardware provides. No lowest common denominator, because nothing is shared.
Compiled for Its Exact Silicon
Each kernel gets its own instruction set, its own errata workarounds, its own vector code at full width. RVV 0.7.1 and RVV 1.0 software run side by side on one machine, each with the toolchain that matches.
Nothing Enforced, Nothing Shared
No affinity lists to maintain or silently override. Hotplug works. SCHED_DEADLINE admits your inference job on the wide cluster. Cpuset isolation behaves as documented.
Placement Is a Decision
Inference and data-parallel jobs deploy to the wide-vector domain, general services to the scalar domains, and the device kernel runs on scalar cores so the expensive vector silicon serves applications only.
Build It With Us
If you make RISC-V silicon, we want to do the bring-up on your parts. If you build boards or systems, we want your platform in our support matrix from day one. If you operate infrastructure, we will run a proof of concept on your real workloads and share the measured results.
Platform Adaptation
Kernel spawning on your boot flow, device kernel enablement for your I/O, one kernel per cluster running at its full vector width.
Proof of Concept
Validate performance, isolation, and operational gains on your real workloads, with every cluster fully enabled.
Upstream & Ecosystem
Push everything into upstream Linux together. The work is open source end to end, and your silicon becomes the reference platform every RISC-V vendor builds on.