On Thu, 4 Sept 2025 at 14:59, Evangelos Petrongonas <[email protected]> wrote: > > On Thu, 4 Sep 2025 11:39:02 +0200, Ard Biesheuvel <[email protected]> wrote: > > On Thu, 4 Sept 2025 at 11:36, Evangelos Petrongonas <[email protected]> > > wrote: > > > > > > On Thu, 4 Sep 2025 09:19:21 +0200, Ard Biesheuvel <[email protected]> wrote: > > > > On Sat, 23 Aug 2025 at 23:47, Ard Biesheuvel <[email protected]> wrote: > > > > > > > > > > (cc Ilias) > > > > > > > > > > Note to akpm: please drop this series for now. > > > > > > > > > > On Fri, 22 Aug 2025 at 04:00, Evangelos Petrongonas > > > > > <[email protected]> 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) <[email protected]> > > > > > > Signed-off-by: Evangelos Petrongonas <[email protected]> > > > > > > --- > > > > > > 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()` (?) >
Indeed. For the series, Reviewed-by: Ard Biesheuvel <[email protected]>
