From: Mike Rapoport <rppt@kernel.org>
To: Jan Engelhardt <ej@inai.de>
Cc: Cong Wang <xiyou.wangcong@gmail.com>,
linux-kernel@vger.kernel.org, pasha.tatashin@soleen.com,
Cong Wang <cwang@multikernel.io>,
Andrew Morton <akpm@linux-foundation.org>,
Baoquan He <bhe@redhat.com>, Alexander Graf <graf@amazon.com>,
Changyuan Lyu <changyuanl@google.com>,
kexec@lists.infradead.org, linux-mm@kvack.org
Subject: Re: [RFC Patch 0/7] kernel: Introduce multikernel architecture support
Date: Sun, 21 Sep 2025 09:24:12 +0300 [thread overview]
Message-ID: <aM-aDAIbKqBMN2DQ@kernel.org> (raw)
In-Reply-To: <3ns36rp5-rp37-1nns-9q43-op05or6s26nq@vanv.qr>
On Sun, Sep 21, 2025 at 07:54:31AM +0200, Jan Engelhardt wrote:
>
> On Friday 2025-09-19 00:25, 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.
>
> I initially read it in such a way that that kernels run without
> supervisor, and thus necessarily cooperatively, on a system.
>
> But then I looked at
> <https://multikernel.io/assets/images/comparison-architecture-diagrams.svg>,
The diagram also oversimplifies containers, with system containers the "OS"
runs inside the container and only the kernel is shared.
It's interesting to hear how the multikernel approach compare to system
containers as well.
> saw that there is a kernel on top of a kernel, to which my reactive
> thought was: "well, that has been done before", e.g. User Mode Linux.
> While UML does not technically talk to hardware directly, continuing
> the thought "what's stopping a willing developer from giving /dev/mem
> to the subordinate kernel".
>
> On second thought, a hypervisor is just some kind of "miniature
> kernel" too (if generalizing very hard).
>
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2025-09-21 6:24 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-18 22:25 Cong Wang
2025-09-18 22:26 ` [RFC Patch 1/7] kexec: Introduce multikernel support via kexec Cong Wang
2025-09-18 22:26 ` [RFC Patch 2/7] x86: Introduce SMP INIT trampoline for multikernel CPU bootstrap Cong Wang
2025-09-18 22:26 ` [RFC Patch 3/7] x86: Introduce MULTIKERNEL_VECTOR for inter-kernel communication Cong Wang
2025-09-18 22:26 ` [RFC Patch 4/7] kernel: Introduce generic multikernel IPI communication framework Cong Wang
2025-09-18 22:26 ` [RFC Patch 5/7] x86: Introduce arch_cpu_physical_id() to obtain physical CPU ID Cong Wang
2025-09-18 22:26 ` [RFC Patch 6/7] kexec: Implement dynamic kimage tracking Cong Wang
2025-09-18 22:26 ` [RFC Patch 7/7] kexec: Add /proc/multikernel interface for " Cong Wang
2025-09-19 10:10 ` [syzbot ci] Re: kernel: Introduce multikernel architecture support syzbot ci
2025-09-19 13:14 ` [RFC Patch 0/7] " Pasha Tatashin
2025-09-20 21:13 ` Cong Wang
2025-09-19 21:26 ` Stefan Hajnoczi
2025-09-20 21:40 ` Cong Wang
2025-09-22 14:28 ` Stefan Hajnoczi
2025-09-22 22:41 ` Cong Wang
2025-09-23 17:05 ` Stefan Hajnoczi
2025-09-24 11:38 ` David Hildenbrand
2025-09-24 12:51 ` Stefan Hajnoczi
2025-09-24 18:28 ` Cong Wang
2025-09-24 19:03 ` Stefan Hajnoczi
2025-09-27 19:42 ` Cong Wang
2025-09-29 15:11 ` Stefan Hajnoczi
2025-10-02 4:17 ` Cong Wang
2025-09-24 17:18 ` Cong Wang
2025-09-21 1:47 ` Hillf Danton
2025-09-22 21:55 ` Cong Wang
2025-09-24 1:12 ` Hillf Danton
2025-09-24 17:30 ` Cong Wang
2025-09-24 22:42 ` Hillf Danton
2025-09-21 5:54 ` Jan Engelhardt
2025-09-21 6:24 ` Mike Rapoport [this message]
2025-09-24 17:51 ` Christoph Lameter (Ampere)
2025-09-24 18:39 ` Cong Wang
2025-09-26 9:50 ` Jarkko Sakkinen
2025-09-27 20:43 ` Cong Wang
2025-09-28 14:22 ` Jarkko Sakkinen
2025-09-28 14:36 ` Jarkko Sakkinen
2025-09-28 14:41 ` Jarkko Sakkinen
2025-09-25 15:47 ` Jiaxun Yang
2025-09-27 20:06 ` Cong Wang
2025-09-26 9:01 ` Jarkko Sakkinen
2025-09-27 20:27 ` Cong Wang
2025-09-27 20:39 ` Pasha Tatashin
2025-09-28 14:08 ` Jarkko Sakkinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aM-aDAIbKqBMN2DQ@kernel.org \
--to=rppt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=changyuanl@google.com \
--cc=cwang@multikernel.io \
--cc=ej@inai.de \
--cc=graf@amazon.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pasha.tatashin@soleen.com \
--cc=xiyou.wangcong@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox