Hi Marc, On 29/04/2021 14:35, Marc Zyngier wrote: > It recently became apparent that using kexec with kexec_file_load() on > arm64 is pretty similar to playing Russian roulette. > > Depending on the amount of memory, the HW supported and the firmware > interface used, your secondary kernel may overwrite critical memory > regions without which the secondary kernel cannot boot (the GICv3 LPI > tables being a prime example of such reserved regions). > > It turns out that there is at least two ways for reserved memory > regions to be described to kexec: /proc/iomem for the userspace > implementation, and memblock.reserved for kexec_file. One is spilled into the other by request_standard_resources()... > And of course, > our LPI tables are only reserved using the resource tree, leading to > the aforementioned stamping. Presumably well after efi_init() has run... > Similar things could happen with ACPI tables as well. efi_init() calls reserve_regions(), which has: | /* keep ACPI reclaim memory intact for kexec etc. */ | if (md->type == EFI_ACPI_RECLAIM_MEMORY) | memblock_reserve(paddr, size); This is also what stops mm from allocating them, as memblock-reserved gets copied into the PG_Reserved flag by free_low_memory_core_early()'s calls to reserve_bootmem_region(). Is your machines firmware putting them in a region with a different type? (The UEFI spec has something to say: see 2.3.6 "AArch64 Platforms": | ACPI Tables loaded at boot time can be contained in memory of type EfiACPIReclaimMemory | (recommended) or EfiACPIMemoryNVS NVS would fail the is_usable_memory() check earlier, so gets treated as nomap) Thanks, James > On my 24xA53 system artificially limited to 256MB of RAM (yes, it > boots with that little memory), trying to kexec a secondary kernel > failed every times. I can only presume that this was mostly tested > using kdump, which preserves the entire kernel memory range. > > This small series aims at triggering a discussion on what are the > expectations for kexec_file, and whether we should unify the two > reservation mechanisms. > > And in the meantime, it gets things going... > > Marc Zyngier (2): > firmware/efi: Tell memblock about EFI reservations > ACPI: arm64: Reserve the ACPI tables in memblock > > arch/arm64/kernel/acpi.c | 1 + > drivers/firmware/efi/efi.c | 23 ++++++++++++++++++++++- > 2 files changed, 23 insertions(+), 1 deletion(-) > _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
