[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAG+v+KZL8teU5ReRNEJ2sdKgP02+K26DLMt2=KapZPfqcSWM3A@mail.gmail.com>
Date: Thu, 25 Sep 2025 02:26:36 -0500
From: Fam Zheng <fam.zheng@...edance.com>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: fam@...hon.net, Dave Hansen <dave.hansen@...el.com>, linux-kernel@...r.kernel.org,
Lukasz Luba <lukasz.luba@....com>, linyongting@...edance.com, songmuchun@...edance.com,
satish.kumar@...edance.com, Borislav Petkov <bp@...en8.de>,
Thomas Gleixner <tglx@...utronix.de>, yuanzhu@...edance.com, Ingo Molnar <mingo@...hat.com>,
Daniel Lezcano <daniel.lezcano@...aro.org>, Zhang Rui <rui.zhang@...el.com>, x86@...nel.org,
liangma@...edance.com, Dave Hansen <dave.hansen@...ux.intel.com>,
"Rafael J. Wysocki" <rafael@...nel.org>, guojinhui.liam@...edance.com, linux-pm@...r.kernel.org,
Thom Hughes <thom.hughes@...edance.com>
Subject: Re: [External] Re: [RFC 0/5] parker: PARtitioned KERnel
> From: "H. Peter Anvin"<hpa@...or.com>
> The difference is that this is highly invasive to the OS, which affects developers and users not wanting this feature.
Yeah that makes sense, thanks for clarifying. By having a hypervisor
at least in early boot of secondary kernels, we don't need to patch
device enumeration etc. In the kernel code.
Once the kernel is up, it can be then promoted to run directly on bare
metal, so zero performance overhead.
Fam
Powered by blists - more mailing lists