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 host 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 host 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.

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.