Mklinux Multikernel Architecture: How to Run Multiple Linux Kernels Simultaneously on Bare Metal

Rethinking Kernel Isolation: The Origins of Multikernel

For a long time, running multiple operating system instances on a single physical machine has been nearly synonymous with "virtualization." Whether using KVM, Xen, or VMware, we've relied on hardware virtualization extensions (Intel VT-x, AMD-V) to achieve isolation. Yet the Mklinux Multikernel project proposes a fundamentally different approach: running multiple independent Linux kernels simultaneously on the same bare-metal machine, with absolutely no dependency on VT-x or other hardware virtualization technologies.

This idea touches on a genuinely imaginative direction in systems architecture — the multikernel architecture. Let's break down the core logic of this approach step by step, from its principles and technical details to real-world use cases.

What Is a Multikernel Architecture

From Monolithic Kernel to Multikernel

Traditional Linux is a monolithic kernel that uniformly manages all CPU cores, memory, and peripherals on a machine. Even on multi-core systems, a single kernel instance schedules all resources.

The core idea of a multikernel architecture is entirely different: partition the hardware resources of a single physical machine so that each partition runs an independent kernel instance. These kernels are isolated from one another, each managing its own allocated CPU cores and memory regions — much like multiple "machines" sharing the same motherboard.

This concept isn't entirely new. The academic Barrelfish operating system (developed collaboratively by Microsoft Research and ETH Zurich) proposed a "multikernel" model, arguing that multi-core machines should be treated as distributed systems where each core runs an independent kernel and cooperates through message passing rather than shared memory.

The Unique Position of Mklinux Multikernel

What makes Mklinux Multikernel significant is that it applies the multikernel concept directly on top of the standard Linux kernel, with a specific emphasis on bare-metal execution and no VT-x requirement. Concretely:

• No hypervisor layer is involved
• No overhead from hardware virtualization is incurred
• Multiple Linux kernels run directly on physical hardware, each "claiming" a portion of the resources

This design puts Mklinux in sharp contrast with traditional virtualization solutions.

Why Bypass Hardware Virtualization

A Deeper Look at Performance and Latency

While hardware virtualization is mature and reliable, the overhead from VM Exit/Enter transitions, Extended Page Tables (EPT/NPT), and similar VT-x mechanisms is non-trivial. For scenarios demanding extreme performance or low latency — such as high-frequency trading systems, industrial control, or real-time audio/video processing — this overhead is far from ideal.

The multikernel approach achieves isolation through physical resource partitioning, eliminating the abstraction cost of the virtualization layer. Each kernel directly operates on the physical CPUs and memory allocated to it, theoretically delivering near-native performance.

Typical Use Cases for Multikernel Architecture

This architecture is particularly attractive in the following scenarios:

• Mixed real-time and general-purpose deployment: Dedicating one kernel exclusively to real-time tasks (e.g., a PREEMPT_RT kernel) while another handles general workloads, with no interference between them.
• Fault isolation and high reliability: A kernel crash in one partition doesn't bring down the others, significantly improving overall system reliability.
• Heterogeneous workload separation: Different kernels can be customized for different workloads (e.g., different scheduling policies, memory management parameters).
• Legacy or non-virtualization hardware: Achieving multi-instance-level isolation on platforms that lack VT-x/AMD-V support.

Technical Challenges and Real-World Constraints of Mklinux Multikernel

Resource Partitioning and the Boot Process

Hard-partitioning a machine's resources among multiple kernels sounds straightforward in concept but is enormously complex in practice. The first major challenge is booting and initialization: after the first kernel starts, how do you get it to "hand off" some CPU cores and memory, then boot a second and third kernel?

This typically involves several key techniques:

• Deep modifications to the boot process (bootloader-level customization)
• Using CPU hotplug mechanisms to dynamically assign cores
• Precisely demarcating physical memory regions to avoid address space conflicts

Peripheral and Interrupt Sharing

An even thornier challenge is peripheral access. How do multiple kernels share devices like NICs, disks, and GPUs? Which kernel should hardware interrupts be routed to? Without a hypervisor acting as a unified arbiter, these questions require carefully designed solutions:

• Using IOMMU for device passthrough, dedicating specific devices to specific kernels
• Establishing inter-kernel coordination channels for time-sharing devices
• Using technologies like SR-IOV to virtualize a single physical device into multiple logical devices

Inter-Kernel Communication

Since each kernel is independent, some form of Inter-Kernel Communication (IKC) mechanism is needed for cooperation. Common implementations include:

• Shared memory regions: Reserving a block of common memory outside each kernel's address space
• Inter-Processor Interrupts (IPI): Using processor interrupt mechanisms to signal peer kernels
• Message queues: Building structured message-passing protocols on top of shared memory

This is precisely what distinguishes the multikernel architecture most fundamentally from the traditional SMP monolithic kernel model: the relationship between kernels is closer to that of distributed nodes than to threads under a unified scheduler.

Comparing Multikernel with VMs and Containers

Understanding the value of multikernel architecture requires placing it within the broader spectrum of isolation technologies:

Approach	Isolation Level	Performance Overhead	Hardware Dependency	Typical Use Case
Virtual Machine (VT-x)	Full isolation (independent kernel + user space)	High	Requires virtualization extensions	Multi-tenant cloud, heterogeneous OS
Container (Docker/LXC)	Namespace + cgroup isolation	Minimal	Shared host kernel	Microservices, CI/CD
Multikernel (Mklinux)	Physical resource partitioning (independent kernels)	Low	No VT-x required	Real-time systems, fault isolation

The comparison reveals that multikernel fills a valuable gap: it delivers the strong isolation guarantees of independent kernels while avoiding the performance costs of virtualization. Its distinction from containers lies in isolation granularity — containers share a single kernel, whereas multikernel gives each instance a completely independent kernel, making security boundaries far clearer.

The Future of Multikernel Architecture

At its current stage of development, Mklinux Multikernel remains experimental — more of a thought-provoking systems research project than a mature solution ready for large-scale production deployment.

But its value lies in challenging the established assumption that "multi-instance must mean virtualization." In an era where container technology has already demonstrated the enormous value of lightweight isolation, multikernel architecture offers another dimension of possibility: achieving more thorough, lower-overhead physical isolation at the hardware level.

For practitioners in the following areas, multikernel architecture is worth keeping an eye on:

• Embedded and industrial control: Physical isolation between real-time kernels and management kernels
• Safety-critical systems: Using hardware-level partitioning to prevent lateral spread of kernel-level attacks
• High-performance computing: Allocating dedicated kernels to specific compute tasks, eliminating scheduling interference
• Edge computing: Running multiple functionally independent systems on resource-constrained hardware

Mklinux Multikernel represents a daring, unconventional direction of exploration in systems software. While it faces significant engineering challenges — including boot process modifications, resource partitioning, and peripheral sharing — and remains some distance from widespread practical use, it reminds us that the evolution of operating system architecture is far from over. Beyond virtualization and containers, multikernel isolation may be a technical direction that has yet to be fully explored.