mklinux runs multiple Linux kernels on one machine without a hypervisor
On August 25, 2026, Cong Wang released mklinux v7.0-mk2, the first ready-to-run build of the multi-kernel concept: several independent Linux kernels on one physical machine, with no hypervisor and no emulation. A promising path to hard isolation — but not yet a production artifact.
August 25, 2026. Cong Wang announces mklinux v7.0-mk2, the first turnkey release of the multi-kernel patchset, based on Linux 7.0. One machine. Several independent Linux kernels run at once, each on its own cores, its own memory, and its own devices. No hypervisor. Nothing is emulated, nothing is trapped.
The concept has been floating around for a year as a pile of patches to assemble by hand. It is now testable with a command — and it reopens a question virtualization thought it had settled.
One fewer hypervisor, several more kernels
The architecture of mklinux fits in one sentence: a host kernel owns a pool of CPUs, memory, and PCI devices, carves that pool into instances, then boots a “spawn” kernel into each instance through kexec_file_load(). Every spawn kernel runs natively on its own resources — no VM exits, no second-level page tables, no emulated device model. The only thing shared is what you choose to share.
The comparison with the two tools everyone knows is instructive. Against virtual machines, there is no hypervisor layer left to pay: no VM-exit path, no two-level address translation. Against containers, instances no longer share a kernel: a lock, a panic, or an exploit in one kernel cannot reach another. That isolation property is the heart of the proposal.
mklinux, by the way, is not the old MkLinux — the Linux port to PowerPC Macintosh systems from the 1990s. The resemblance stops at the name.
The real novelty: hot resource migration
The most interesting part of the project is not the initial carving but its reversibility. Instances are declared through a device tree exposed in /sys/fs/multikernel/. Device-tree overlays move memory, CPUs, and devices between the pool and running instances, without a reboot.
Concretely: an instance can be shut down, its resources reclaimed, then respawned with a different kernel. You can swap a kernel’s version or configuration on the fly, without touching the others. That is resource management of a new kind — orchestrators could treat instances as first-class resources, with no new syscall required.
# The device-tree interface that declares multi-kernel instances
ls /sys/fs/multikernel/
# The spawn-kernel boot mechanism mklinux relies on
kexec --load /boot/vmlinuz-spawn --initrd=/boot/initrd-spawn.img --reuse-cmdline
kexec -eEarly and provocative benchmarks
The release ships with a few numbers, and they should be taken for what they are: signals, not a verdict. In a 2-core / 2-vCPU showdown, multi-kernel beats KVM. In a 24-core configuration, two kernels beat one. Two data points, with no detailed methodology in the announcement — no memory-bandwidth figures, no I/O breakdown.
The direction is still consistent with the theory: removing the hypervisor layer and the second-level page tables should reduce overhead, and the 24-core result hints that scheduler contention inside a single kernel on many cores is a real bottleneck that splitting could relieve.
The trade-offs nobody talks enough about
The project is honest about its limits, and they are structural.
- Memory fragmentation. Carving physical memory into disjoint pools means you cannot dynamically rebalance pressure across workloads the way a single kernel with cgroups can. A starved instance next to a fat one stays stuck, short of tearing down and respawning with a new overlay — a reboot-equivalent for that instance.
- Static device assignment. Each kernel receives its devices at boot. Hot-plug depends on the instance’s drivers and the host’s willingness to relinquish the hardware. This is not a hypervisor’s mediated passthrough, with live migration.
- Firmware interaction. The host initializes the hardware; spawn kernels kexec into a pre-initialized state. That works for most PCI devices, but anything expecting a full firmware handoff — some GPUs, some accelerators — may require the host to never touch it at all, costing the host access to that hardware.
You are not just partitioning at the software level: you are partitioning at the hardware level.
Who this helps right now
The project says it plainly: mainline inclusion is uncertain and probably far off. The patchset touches memory management, device assignment, and boot paths all at once — three areas maintainers scrutinize with justified caution, especially when the overlay mechanism adds complexity to the device model.
The credible near-term use cases are therefore niches, but real niches. An NFV (network function virtualization) box that wants deterministic latency for a dedicated data-plane kernel while a control-plane kernel handles management maps cleanly onto it. The same goes for hardware-in-the-loop testing: spin up a kernel with the exact device assignments you want, tear it down, reconfigure, repeat. For kernel exploit or stability work, a panic in a spawn kernel does not take down the host — a real workflow win, even if niche.
Verdict
If you build specialized appliances, telco edge, or kernel tooling, mklinux is worth evaluating now: isolation without the hypervisor tax is a rare property, and the overlay-based resource migration is genuinely novel. But treat it as a laboratory, not a platform: the performance data is too thin, and the host kernel’s security surface has not yet had the review it deserves.
If you run a conventional VM fleet, leave it alone for now. Proven virtualization is still the right answer to your workloads, and the signal to follow here is not “migrate” but “watch the mailing list” — that is where the technical debate starts, and where the concept’s viability will be decided.