Hi Jiaxun, On Thu, Sep 25, 2025 at 8:48 AM Jiaxun Yang <[email protected]> wrote: > > > > > 2025年9月19日 06:25，Cong Wang <[email protected]> 写道： > > > > 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. > > Hi Cong, > > Sorry for chime in here, and thanks for brining replicated-kernel back to the > life.
I have to clarify: in my design, kernel is not replicated. It is the opposite, I intend to have diversified kernels for highly customization for each application. > > I have some experience on original Popcorn Linux [1] [2], which seems to be > the > root of most code in this series, please see my comments below. > > > > > The multikernel architecture provides several key benefits: > > - Improved fault isolation between different workloads > > - Enhanced security through kernel-level separation > > I’d agree with Stefen’s comments [3], an "isolation” solution is critical for > adaptation > of multikernel OS, given that multi-tenant system is almost everywhere. > > Also allowing other kernel to inject IPI without any restriction can impose > DOS attack > risk. This is true. Like I mentioned, this is also a good opportunity to invite hardware (CPU) vendors to catch up with software, for example, they could provide hardware-filtering for IPI via MSR. If we look at how virtualization evolves, it is the hardware follows software. VMCS comes after Xen or KVM, VPDA comes after virtio. > > > - Better resource utilization than traditional VM (KVM, Xen etc.) > > - Potential zero-down kernel update with KHO (Kernel Hand Over) > > > > Architecture Overview: > > The implementation leverages kexec infrastructure to load and manage > > multiple kernel images, with each kernel instance assigned to specific > > CPU cores. Inter-kernel communication is facilitated through a dedicated > > IPI framework that allows kernels to coordinate and share information > > when necessary. > > > > Key Components: > > 1. Enhanced kexec subsystem with dynamic kimage tracking > > 2. Generic IPI communication framework for inter-kernel messaging > > I actually have concerns over inter-kernel communication. The origin Popcorn > IPI protocol, which seems to be inherited here, was designed as a prototype, > without much consideration on the ecosystem. It would be nice if we can reused > existing infra design for inter kernel communication. Popcorn does the opposite: it still stays with a single image which is essentially against isolation. In fact, I also read its latest paper this year, I don't see any essential change on this big direction: https://www.ssrg.ece.vt.edu/papers/asplos25.pdf This is why fundamentally Popcorn is not suitable for isolation. Please don't get me wrong: I am not questioning its usefulness, it is just simply two opposite directions. I wish people best luck on the heterogeneous ISA design, and I hope major CPU vendors will catch up with you too. :) > > I would suggest look into OpenAMP [4] and remoteproc subsystem in kernel. They > already have mature solutions on communication between different kernels over > coherent > memory and mailboxes (rpmsg [5] co). They also defined ELF extensions to pass > side band > information for other kernel images. Thanks for the pointers. Jim Huang also shared his idea on remoteproc at LinuxCon this year. After evaluations, I found remoteproc may not be as good as IPI. Remoteproc is designed for heterogeneous systems with different architectures, adding unnecessary abstraction layers. > > Linaro folks are also working on a new VirtIO transport called virtio-msg > [6], [7], which is designed > with Linux-Linux hardware partitioning scenario in mind. I think there is still a fundamental difference between static partitioning. and elastic resource allocation. Static partitioning can be achieved as a default case of dynamic allocation when resources remain unchanged, but the reverse is not possible. Hope this makes sense to you. Regards, Cong Wang
