All of lore.kernel.org
 help / color / mirror / Atom feed
From: Evangelos Petrongonas <epetron@amazon.de>
To: <ardb@kernel.org>, Evangelos Petrongonas <epetron@amazon.de>,
	"Ilias Apalodimas" <ilias.apalodimas@linaro.org>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: <bhe@redhat.com>, <changyuanl@google.com>, <graf@amazon.com>,
	<kexec@lists.infradead.org>, <linux-efi@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>,
	<nh-open-source@amazon.com>, <rppt@kernel.org>
Subject: Re: Re: [PATCH v3 2/2] efi: Support booting with kexec handover (KHO)
Date: Thu, 4 Sep 2025 09:34:09 +0000	[thread overview]
Message-ID: <20250904093455.73184-1-epetron@amazon.de> (raw)
In-Reply-To: <CAMj1kXFzKzpoqczq7Rk-u+kKLFO057XEXMD+KM=iRMMsoUZbJA@mail.gmail.com>

On Thu, 4 Sep 2025 09:19:21 +0200, Ard Biesheuvel <ardb@kernel.org> wrote:
> On Sat, 23 Aug 2025 at 23:47, Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > (cc Ilias)
> >
> > Note to akpm: please drop this series for now.
> >
> > On Fri, 22 Aug 2025 at 04:00, Evangelos Petrongonas <epetron@amazon.de> wrote:
> > >
> > > When KHO (Kexec HandOver) is enabled, it sets up scratch memory regions
> > > early during device tree scanning. After kexec, the new kernel
> > > exclusively uses this region for memory allocations during boot up to
> > > the initialization of the page allocator
> > >
> > > However, when booting with EFI, EFI's reserve_regions() uses
> > > memblock_remove(0, PHYS_ADDR_MAX) to clear all memory regions before
> > > rebuilding them from EFI data. This destroys KHO scratch regions and
> > > their flags, thus causing a kernel panic, as there are no scratch
> > > memory regions.
> > >
> > > Instead of wholesale removal, iterate through memory regions and only
> > > remove non-KHO ones. This preserves KHO scratch regions, which are
> > > good known memory, while still allowing EFI to rebuild its memory map.
> > >
> > > Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> > > Signed-off-by: Evangelos Petrongonas <epetron@amazon.de>
> > > ---
> > > Changes in v3:
> > >         - Improve the code comments, by stating that the scratch regions are
> > >         good known memory
> > >
> > > Changes in v2:
> > >         - Replace the for loop with for_each_mem_region
> > >         - Fix comment indentation
> > >         - Amend commit message to specify that scratch regions
> > >         are known good regions
> > >
> > >  drivers/firmware/efi/efi-init.c | 29 +++++++++++++++++++++++++----
> > >  1 file changed, 25 insertions(+), 4 deletions(-)
> > >
> >
> > I'd rather drop the memblock_remove() entirely if possible. Could we
> > get some insight into whether memblocks are generally already
> > populated at this point during the boot?
> >
> >
> 
> Ping?

Hey Ard I was AFK travelling. I am back now and will get to it.
PS: Keen to meet you later today in the KVM Forum.

Kind Regards,
Evangelos




Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597

  reply	other threads:[~2025-09-04 10:48 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-21 17:58 [PATCH v3 0/2] efi: Fix EFI boot with kexec handover (KHO) Evangelos Petrongonas
2025-08-21 17:58 ` [PATCH v3 1/2] kexec: introduce is_kho_boot() Evangelos Petrongonas
2025-09-09 12:13   ` Pratyush Yadav
2025-08-21 17:59 ` [PATCH v3 2/2] efi: Support booting with kexec handover (KHO) Evangelos Petrongonas
2025-08-23 21:47   ` Ard Biesheuvel
2025-09-04  7:19     ` Ard Biesheuvel
2025-09-04  9:34       ` Evangelos Petrongonas [this message]
2025-09-04  9:39         ` Ard Biesheuvel
2025-09-04 12:57           ` Evangelos Petrongonas
2025-09-08  5:50             ` Ard Biesheuvel
2025-09-09 12:17   ` Pratyush Yadav
2025-08-21 20:58 ` [PATCH v3 0/2] efi: Fix EFI boot " Andrew Morton

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=20250904093455.73184-1-epetron@amazon.de \
    --to=epetron@amazon.de \
    --cc=akpm@linux-foundation.org \
    --cc=ardb@kernel.org \
    --cc=bhe@redhat.com \
    --cc=changyuanl@google.com \
    --cc=graf@amazon.com \
    --cc=ilias.apalodimas@linaro.org \
    --cc=kexec@lists.infradead.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nh-open-source@amazon.com \
    --cc=rppt@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.