On Sat, Sep 27, 2025 at 4:27 PM Cong Wang <[email protected]> wrote: > > 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? :-)
Solaris kernel zones use sun4v hypervisor to protect isolation. There is no such thing on x86 and arm. Pasha
