[PATCH v3 0/2] efi: Fix EFI boot with kexec handover (KHO)

[PATCH v3 0/2] efi: Fix EFI boot with kexec handover (KHO)

[Evangelos Petrongonas]

This patch series fixes a kernel panic that occurs when booting with
both EFI and KHO (Kexec HandOver) enabled.

The issue arises because EFI's `reserve_regions()` clears all memory
regions with `memblock_remove(0, PHYS_ADDR_MAX)` before rebuilding them
from EFI data. This destroys KHO scratch regions that were set up early
during device tree scanning, causing a panic as the kernel has no valid
memory regions for early allocations.

The first patch introduces `is_kho_boot()` to allow early boot
components to reliably detect if the kernel was booted via KHO-enabled
kexec. The existing `kho_is_enabled()` only checks the command line and
doesn't verify if an actual KHO FDT was passed.

The second patch modifies EFI's `reserve_regions()` to selectively
remove only non-KHO memory regions when KHO is active, preserving the
critical scratch regions while still allowing EFI to rebuild its memory
map.

The patchset was developed/tested on arm64.

Main Changes in v3 (smaller changes can be found in individual patches):
    - Condition is_kho_boot only on the existence of a KHO FDT
    - Add Reviewed-by/Acked-by

Main Changes in v2:
    - Introduce is_kho_boot()
    - Replace manual loop with for_each_mem_region macro

Evangelos Petrongonas (2):
  kexec: introduce is_kho_boot()
  efi: Support booting with kexec handover (KHO)

 drivers/firmware/efi/efi-init.c | 29 +++++++++++++++++++++++++----
 include/linux/kexec_handover.h  |  6 ++++++
 kernel/kexec_handover.c         | 20 ++++++++++++++++++++
 3 files changed, 51 insertions(+), 4 deletions(-)

-- 
2.47.3




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

[PATCH v3 1/2] kexec: introduce is_kho_boot()

[Evangelos Petrongonas]

During early initialisation, after a kexec, other components, like EFI
need to know if a KHO enabled kexec is performed. The `kho_is_enabled`
function is not enough as in the early stages, it only reflects
whether the cmdline has KHO enabled, not if an actual KHO FDT exists.

Extend the KHO API with `is_kho_boot()` to provide a way for components
to check if a KHO enabled kexec is performed.

Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Signed-off-by: Evangelos Petrongonas <epetron@amazon.de>
---
Changes in v3:
	- Condition Only on the existense of the KHO FDT and ignore the
	cmdline `kho` parameter

 include/linux/kexec_handover.h |  6 ++++++
 kernel/kexec_handover.c        | 20 ++++++++++++++++++++
 2 files changed, 26 insertions(+)

diff --git a/include/linux/kexec_handover.h b/include/linux/kexec_handover.h
index 348844cffb13..559d13a3bc44 100644
--- a/include/linux/kexec_handover.h
+++ b/include/linux/kexec_handover.h
@@ -40,6 +40,7 @@ struct kho_serialization;
 
 #ifdef CONFIG_KEXEC_HANDOVER
 bool kho_is_enabled(void);
+bool is_kho_boot(void);
 
 int kho_preserve_folio(struct folio *folio);
 int kho_preserve_phys(phys_addr_t phys, size_t size);
@@ -60,6 +61,11 @@ static inline bool kho_is_enabled(void)
 	return false;
 }
 
+static inline bool is_kho_boot(void)
+{
+	return false;
+}
+
 static inline int kho_preserve_folio(struct folio *folio)
 {
 	return -EOPNOTSUPP;
diff --git a/kernel/kexec_handover.c b/kernel/kexec_handover.c
index 69b953551677..52e80e0c2238 100644
--- a/kernel/kexec_handover.c
+++ b/kernel/kexec_handover.c
@@ -925,6 +925,26 @@ static const void *kho_get_fdt(void)
 	return kho_in.fdt_phys ? phys_to_virt(kho_in.fdt_phys) : NULL;
 }
 
+/**
+ * is_kho_boot - check if current kernel was booted via KHO-enabled
+ * kexec
+ *
+ * This function checks if the current kernel was loaded through a kexec
+ * operation with KHO enabled, by verifying that a valid KHO FDT
+ * was passed.
+ *
+ * Note: This function returns reliable results only after
+ * kho_populate() has been called during early boot. Before that,
+ * it may return false even if KHO data is present.
+ *
+ * Return: true if booted via KHO-enabled kexec, false otherwise
+ */
+bool is_kho_boot(void)
+{
+	return !!kho_get_fdt();
+}
+EXPORT_SYMBOL_GPL(is_kho_boot);
+
 /**
  * kho_retrieve_subtree - retrieve a preserved sub FDT by its name.
  * @name: the name of the sub FDT passed to kho_add_subtree().
-- 
2.47.3




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

[PATCH v3 2/2] efi: Support booting with kexec handover (KHO)

[Evangelos Petrongonas]

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(-)

diff --git a/drivers/firmware/efi/efi-init.c b/drivers/firmware/efi/efi-init.c
index a00e07b853f2..a65c2d5b9e7b 100644
--- a/drivers/firmware/efi/efi-init.c
+++ b/drivers/firmware/efi/efi-init.c
@@ -12,6 +12,7 @@
 #include <linux/efi.h>
 #include <linux/fwnode.h>
 #include <linux/init.h>
+#include <linux/kexec_handover.h>
 #include <linux/memblock.h>
 #include <linux/mm_types.h>
 #include <linux/of.h>
@@ -164,12 +165,32 @@ static __init void reserve_regions(void)
 		pr_info("Processing EFI memory map:\n");
 
 	/*
-	 * Discard memblocks discovered so far: if there are any at this
-	 * point, they originate from memory nodes in the DT, and UEFI
-	 * uses its own memory map instead.
+	 * Discard memblocks discovered so far except for KHO scratch
+	 * regions. Most memblocks at this point originate from memory nodes
+	 * in the DT and UEFI uses its own memory map instead. However, if
+	 * KHO is enabled, scratch regions, which are good known memory
+	 * must be preserved.
 	 */
 	memblock_dump_all();
-	memblock_remove(0, PHYS_ADDR_MAX);
+
+	if (is_kho_boot()) {
+		struct memblock_region *r;
+
+		/* Remove all non-KHO regions */
+		for_each_mem_region(r) {
+			if (!memblock_is_kho_scratch(r)) {
+				memblock_remove(r->base, r->size);
+				r--;
+			}
+		}
+	} else {
+		/*
+		 * KHO is disabled. Discard memblocks discovered so far:
+		 * if there are any at this point, they originate from memory
+		 * nodes in the DT, and UEFI uses its own memory map instead.
+		 */
+		memblock_remove(0, PHYS_ADDR_MAX);
+	}
 
 	for_each_efi_memory_desc(md) {
 		paddr = md->phys_addr;
-- 
2.47.3




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

Re: [PATCH v3 0/2] efi: Fix EFI boot with kexec handover (KHO)

[Andrew Morton]

On Thu, 21 Aug 2025 17:58:58 +0000 Evangelos Petrongonas <epetron@amazon.de> wrote:

> This patch series fixes a kernel panic that occurs when booting with
> both EFI and KHO (Kexec HandOver) enabled.
> 
> The issue arises because EFI's `reserve_regions()` clears all memory
> regions with `memblock_remove(0, PHYS_ADDR_MAX)` before rebuilding them
> from EFI data. This destroys KHO scratch regions that were set up early
> during device tree scanning, causing a panic as the kernel has no valid
> memory regions for early allocations.

Do you think we should backport this into 6.16.x kernels?  If so, is
there a suitable Fixes: target we can include?

Re: [PATCH v3 2/2] efi: Support booting with kexec handover (KHO)

[Ard Biesheuvel]

(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?


> diff --git a/drivers/firmware/efi/efi-init.c b/drivers/firmware/efi/efi-init.c
> index a00e07b853f2..a65c2d5b9e7b 100644
> --- a/drivers/firmware/efi/efi-init.c
> +++ b/drivers/firmware/efi/efi-init.c
> @@ -12,6 +12,7 @@
>  #include <linux/efi.h>
>  #include <linux/fwnode.h>
>  #include <linux/init.h>
> +#include <linux/kexec_handover.h>
>  #include <linux/memblock.h>
>  #include <linux/mm_types.h>
>  #include <linux/of.h>
> @@ -164,12 +165,32 @@ static __init void reserve_regions(void)
>                 pr_info("Processing EFI memory map:\n");
>
>         /*
> -        * Discard memblocks discovered so far: if there are any at this
> -        * point, they originate from memory nodes in the DT, and UEFI
> -        * uses its own memory map instead.
> +        * Discard memblocks discovered so far except for KHO scratch
> +        * regions. Most memblocks at this point originate from memory nodes
> +        * in the DT and UEFI uses its own memory map instead. However, if
> +        * KHO is enabled, scratch regions, which are good known memory
> +        * must be preserved.
>          */
>         memblock_dump_all();
> -       memblock_remove(0, PHYS_ADDR_MAX);
> +
> +       if (is_kho_boot()) {
> +               struct memblock_region *r;
> +
> +               /* Remove all non-KHO regions */
> +               for_each_mem_region(r) {
> +                       if (!memblock_is_kho_scratch(r)) {
> +                               memblock_remove(r->base, r->size);
> +                               r--;
> +                       }
> +               }
> +       } else {
> +               /*
> +                * KHO is disabled. Discard memblocks discovered so far:
> +                * if there are any at this point, they originate from memory
> +                * nodes in the DT, and UEFI uses its own memory map instead.
> +                */
> +               memblock_remove(0, PHYS_ADDR_MAX);
> +       }
>
>         for_each_efi_memory_desc(md) {
>                 paddr = md->phys_addr;
> --
> 2.47.3
>
>
>
>
> 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
>

Re: [PATCH v3 2/2] efi: Support booting with kexec handover (KHO)

[Ard Biesheuvel]

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?

Re: Re: [PATCH v3 2/2] efi: Support booting with kexec handover (KHO)

[Evangelos Petrongonas]

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

Re: Re: [PATCH v3 2/2] efi: Support booting with kexec handover (KHO)

[Ard Biesheuvel]

On Thu, 4 Sept 2025 at 11:36, Evangelos Petrongonas <epetron@amazon.de> wrote:
>
> 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.
>

Yes, let's catch up!

Re: Re: Re: [PATCH v3 2/2] efi: Support booting with kexec handover (KHO)

[Evangelos Petrongonas]

On Thu, 4 Sep 2025 11:39:02 +0200, Ard Biesheuvel <ardb@kernel.org> wrote:
> On Thu, 4 Sept 2025 at 11:36, Evangelos Petrongonas <epetron@amazon.de> wrote:
> >
> > 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.
> >
> 
> Yes, let's catch up!
> 
> 

I did some testing on qemu with memblock and EFI debug enabled

(`memblock=debug efi=debug`) and no KHO.
We see that `memblock_dump_all()` in `reserve_regions()` outputs:
```
[    0.000000] MEMBLOCK configuration:
[    0.000000]  memory size = 0x0000000200000000 reserved size = 0x000000000db5383e
[    0.000000]  memory.cnt  = 0x7
[    0.000000]  memory[0x0]	[0x0000000040000000-0x000000023c76ffff], 0x00000001fc770000 bytes on node 0 flags: 0x0
...
[    0.000000]  reserved.cnt  = 0xf
[    0.000000]  reserved[0x0]	[0x00000000fe000000-0x00000000ffffffff], 0x0000000002000000 bytes flags: 0x20
```

Moreover checking the code, the boot flow  (at least on arm64)
populates memblocks from DT memory nodes via
`early_init_dt_add_memory_arch()` before `efi_init()` is called

`setup_arch()` -> `setup_machine_fdt()` -> `early_init_dt_scan()` ->
`early_init_dt_scan_memory()` -> `early_init_dt_add_memory_arch()` ->
`memblock_add()`

As a result, it seems that memblocks ARE populated when calling the
`reserve_regions()`. So looks like  we still need the
`memblock_remove()` (?)





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