On Fri, Sep 26, 2025 at 2:01 AM Jarkko Sakkinen <[email protected]> wrote: > > On Thu, Sep 18, 2025 at 03:25:59PM -0700, Cong Wang wrote: > > This patch series introduces multikernel architecture support, enabling > > multiple independent kernel instances to coexist and communicate on a > > single physical machine. Each kernel instance can run on dedicated CPU > > cores while sharing the underlying hardware resources. > > > > The multikernel architecture provides several key benefits: > > - Improved fault isolation between different workloads > > - Enhanced security through kernel-level separation > > - Better resource utilization than traditional VM (KVM, Xen etc.) > > - Potential zero-down kernel update with KHO (Kernel Hand Over) > > This list is like asking AI to list benefits, or like the whole cover > letter has that type of feel.
Sorry for giving you that feeling. Please let me know how I can improve it for you. > > I'd probably work on benchmarks and other types of tests that can > deliver comparative figures, and show data that addresses workloads > with KVM, namespaces/cgroups and this, reflecting these qualities. Sure, I think performance comes after usability, not vice versa. > > E.g. consider "Enhanced security through kernel-level separation". > It's a pre-existing feature probably since dawn of time. Any new layer > makes obviously more complex version "kernel-level separation". You'd > had to prove that this even more complex version is more secure than > pre-existing science. Apologize for this. Do you mind explaining why this is more complex than the KVM/Qemu/vhost/virtio/VDPA stack? > > kexec and its various corner cases and how this patch set addresses > them is the part where I'm most lost. Sorry for that. I will post Youtube videos to explain kexec in detail, please follow our Youtube channel if you are interested. (I don't want to post a link here in case people think I am promoting my own interest, please email me privately.) > > If I look at one of multikernel distros (I don't know any other > tbh) that I know it's really VT-d and that type of hardware > enforcement that make Qubes shine: > > https://www.qubes-os.org/ > > That said, I did not look how/if this is using CPU virtualization > features as part of the solution, so correct me if I'm wrong. Qubes OS is based on Xen: https://en.wikipedia.org/wiki/Qubes_OS > > I'm not entirely sure whether this is aimed to be alternative to > namespaces/cgroups or vms but more in the direction of Solaris Zones > would be imho better alternative at least for containers because > it saves the overhead of an extra kernel. There's also a patch set > for this: > > https://lwn.net/Articles/780364/?ref=alian.info Solaris Zones also share a single kernel. Or maybe I guess you meant Kernel Zones? Isn't it a justification for our multikernel approach for Linux? :-) BTW, it is less flexible since it completely isolates kernels without inter-kernel communication. With our design, you can still choose not to use inter-kernel IPI's, which turns dynamic into static. > > VM barrier combined with IOMMU is pretty strong and hardware > enforced, and with polished configuration it can be fairly > performant (e.g. via page cache bypass and stuff like that) > so really the overhead that this is fighting against is > context switch overhead. > > In security I don't believe this has any realistic chances to > win over VMs and IOMMU... I appreciate you sharing your opinions. I hope my information helps. Regards, Cong Wang
