Frequently Asked Questions

Multikernel is an architecture that runs multiple kernels in parallel without relying on virtualization. Unlike the original academic definition which treats machines as distributed systems with message-passing cores, our implementation focuses on practical kernel isolation and performance optimization.

Containers share a single kernel, which limits isolation. VMs provide isolation but add virtualization overhead. Multikernel provides true kernel-level isolation with near bare-metal performance and dynamic resource allocation, without the overhead of a hypervisor.

High-performance computing, AI/ML training and inference, latency-sensitive services, and workloads with strict security or isolation requirements gain the most from multikernel architecture.

Yes. Multikernel maintains full compatibility with existing Linux applications and system interfaces. Our implementation introduces only minimal, non-intrusive kernel modifications that preserve complete API and ABI compatibility. Your applications run unchanged.

Yes. Multikernel integrates with standard cloud and on-premises infrastructure, providing a practical migration path from traditional virtualization or container environments.

In our split-kernel architecture, the device-kernel manages hardware and device processing, while application kernels run workloads with dedicated CPU cores and no kernel context switching. Hardware resources like I/O queues are allocated exclusively to each application kernel by the device-kernel, providing both strong isolation and near bare-metal performance. Modern servers with 256+ cores make this dedicated allocation practical at scale.

Modern cloud workloads require elasticity. Static partitioning can be achieved as a special case of dynamic allocation when resources remain unchanged, but the reverse is not possible. Dynamic allocation is essential for efficient resource utilization at scale.

AWS proved the architecture. Nitro moved device processing off the main CPUs into dedicated offload cards, kept the network stack in the guest, and reduced the data path between card and instance to descriptor rings and DMA. Multikernel delivers the same design in software: the device-kernel plays the role of the offload card, owning physical devices and steering traffic, while each app-kernel keeps its own network stack and exchanges only descriptors over shared-memory rings. The difference is that Nitro is custom hardware you can only rent from AWS. Multikernel runs on the servers and standard NICs you already own.

Unikernels eliminate syscall overhead, but modern CPUs already provide highly optimized syscall performance, making this benefit marginal. Most unikernels still rely on virtualization layers, inheriting their performance penalties. Multikernel delivers superior isolation and performance without virtualization overhead or the need to rebuild applications for specialized kernel environments.

Jailhouse only supports static partitioning and relies on traditional virtualization mechanisms like VMEXIT and SR-IOV. Multikernel provides dynamic resource allocation and avoids virtualization overhead entirely while maintaining compatibility with existing virtualization technologies when needed.

Directvisor and similar de-virtualization approaches still fundamentally rely on virtualization infrastructure. Virtualization followed by de-virtualization equals no virtualization, making it more efficient to eliminate virtualization layers entirely from the start.

Yes, and it is more common than many realize. Cloud providers run VMs for tenants, and those tenants often run their own VMs or containers with hypervisor-based isolation inside. Kubernetes nodes on cloud instances, CI/CD pipelines spinning up VMs, and security sandboxes all create nested virtualization in practice. Each layer multiplies overhead: additional VM exits, shadow page tables, and emulated I/O compound latency significantly. Multikernel eliminates this problem entirely by providing kernel-level isolation without any hypervisor, removing the need to nest virtualization layers in the first place.

No. While SR-IOV and hardware acceleration significantly reduce virtualization overhead, they cannot eliminate it entirely. VM exits, IOMMU translations, and hypervisor intervention for privileged operations still introduce measurable latency. Multikernel bypasses these virtualization layers completely, achieving near bare-metal performance without hardware acceleration dependencies.

SR-IOV is fast and IOMMU overhead can be minimal when properly configured. However, VFs provide coarse-grained isolation mechanisms. Multikernel leverages hardware queues as more flexible and elastic resources, offering finer granularity and dynamic resource allocation compared to the static nature of VFs.

Our architecture provides hardware-enforced isolation between workloads, minimizes attack surfaces through tailored kernels, and supports confidential computing for sensitive data processing. By running applications directly in initramfs without a full OS, we further reduce the attack surface compared to traditional environments.

The kernel itself is the trust boundary. While a compromised kernel could potentially affect other kernels on the same node, this risk is mitigated through kernel signing via kexec, kernel lockdown, and memory encryption using confidential computing technologies.

KVM runs guests only on cores with the H (Hypervisor) extension, and AI cores such as those on the SpacemiT K3 lack it, so KVM can only divide the uniform general-purpose cluster. It also needs one host kernel that owns every core, which brings back the mismatched vector widths that keep a single kernel from running the machine safely. See our heterogeneous RISC-V post.

Linux intersects the ISA extensions of every core at boot, and KVM checks that machine-wide result. One core without H removes H from the intersection, so KVM fails with "hypervisor extension not available" even on cores that support it.

No. Vector save buffers are sized for the boot core, so a 1024-bit core writes 4 KB into a 1 KB buffer on its first context switch and corrupts the kernel heap. Making it safe means pinning tasks to one cluster, which brings back the costs described in our heterogeneous RISC-V post.

Partly. OpenSBI domains use PMP to enforce fixed hart and memory partitions in firmware, which suits a static boundary such as the split between two clusters. But they are set once at boot with few PMP entries, while multikernel spawns kernels, moves memory, and shares regions at runtime.

Supervisor Domains are draft RISC-V extensions that let M-mode firmware confine each hart, device, and interrupt to a domain using page-granular memory protection tables. They do not replace multikernel: every domain still needs its own kernel. Supervisor Domains are the hardware for running multiple kernels, and multikernel is the software that runs them.

On RISC-V, yes. They confine CPU and DMA accesses per kernel, allow memory to move and be shared between kernels at runtime, scale to many kernels, and do not require the H extension. Without them, isolation relies on each kernel seeing only its assigned resources plus an IOMMU. No shipping silicon implements them yet.