Frequently Asked Questions
Common questions about multikernel technology, architecture, and implementation.
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.
Unlike containers that share a kernel or VMs that add virtualization overhead, our multikernel architecture provides true kernel isolation with near bare-metal performance, dynamic resource allocation, and application-optimized environments.
High-performance computing, AI/ML frameworks, latency-sensitive services, and applications with strict security requirements gain the most advantage from our multikernel architecture.
Yes, our solution is designed to integrate with standard cloud and on-premises infrastructure, providing a seamless transition path from traditional virtualization or container environments.
Absolutely. Multikernel maintains 100% compatibility with existing Linux applications and system interfaces. Our implementation introduces only minimal, non-intrusive kernel modifications that preserve full API and ABI compatibility, ensuring your applications run unchanged without any modifications or performance degradation.
While unikernels eliminate syscall overhead, modern CPUs already provide highly optimized syscall performance, making this benefit marginal. Most unikernels still rely on virtualization layers, inheriting their performance penalties. Like unikernels, multikernel avoids a full OS by running applications and their necessary dependencies directly in initramfs, but delivers superior isolation and performance without virtualization overhead or the complexity of rebuilding applications for specialized kernel environments.
Jailhouse only supports static partitioning, while multikernel provides dynamic resource allocation essential for modern cloud computing. Additionally, Jailhouse relies on traditional virtualization mechanisms like VMEXIT and SR-IOV. Multikernel avoids virtualization overhead entirely while maintaining compatibility with existing virtualization technologies when needed.
Dynamic resource allocation is essential for modern cloud computing. Static partitioning can be achieved as a special case of dynamic allocation when resources remain unchanged, but the reverse is not possible.
Directvisor and similar de-virtualization approaches still fundamentally rely on virtualization infrastructure. From our perspective, virtualization followed by de-virtualization equals no virtualization—making it more efficient to eliminate virtualization layers entirely from the start rather than adding complexity to remove them later.
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 and CPU cycles. Multikernel bypasses these virtualization layers intentionally and completely, achieving near bare-metal performance without hardware acceleration dependencies.
Nothing is inherently wrong with SR-IOV—it's actually quite 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.
No. Multikernels receive dedicated physical CPU cores without kernel context switching, leveraging the abundance of cores in modern servers (typically 256+ cores). For I/O hardware, we utilize hardware queues as more flexible and elastic resources for exclusive per-kernel allocation.
Our architecture provides hardware-enforced isolation between workloads, minimizes attack surfaces through tailored kernels, and offers enhanced confidential computing capabilities for sensitive data processing. By avoiding a full OS and running applications directly in initramfs, we further reduce the attack surface compared to traditional operating systems.
Multikernel relies on kernel-enforced isolation, making the kernel itself the trust boundary. While a malicious kernel could potentially disrupt other kernels on the same node, this risk can be mitigated through kernel signing via kexec, kernel lockdown, and memory encryption using confidential computing technologies.