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 takes the hardware's side: one Linux kernel per cluster, each compiled for its exact silicon, 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 put it only where it earns its keep. Heterogeneous width is not a mistake in these products. It is the product. The machine will be partitioned no matter what you do; the only question is whether the partition is a boundary you designed or an accident 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 headline cluster, the reason the chip exists, stays dark.
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 scalar cores pay for the AI cluster they never touch.
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 capability word describes silicon its programs will actually run on, and the C library selects the vector routines the hardware really has. 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. Cpusets do what the documentation says.
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 let the results speak.
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.