This series is a complete departure from the approach I initially sent almost a month ago[1]. Instead of trying to teach EFI, ACPI and other subsystem to use memblock, I've decided to stick with the iomem resource tree and use that exclusively for arm64. This means that my current approach is (despite what I initially replied to both Dave and Catalin) to provide an arm64-specific implementation of arch_kexec_locate_mem_hole() which walks the resource tree and excludes ranges of RAM that have been registered for any odd purpose. This is exactly what the userspace implementation does, and I don't really see a good reason to diverge from it. Again, this allows my Synquacer board to reliably use kexec_file_load with as little as 256M, something that would always fail before as it would overwrite most of the reserved tables. Obviously, this is now at least 5.14 material. Given how broken kexec_file_load is for non-crash kernels on arm64 at the moment, should we at least disable it in 5.13 and all previous stable kernels? Thanks, M. [1] https://lore.kernel.org/r/20210429133533.1750721-1-maz@xxxxxxxxxx Marc Zyngier (4): kexec_file: Make locate_mem_hole_callback global kernel/resource: Populate child pointer in find_next_iomem_res() kernel/resource: Add walk_excluding_child_res() helper arm64: kexec_image: Implement arch_kexec_locate_mem_hole() arch/arm64/kernel/kexec_image.c | 45 ++++++++++++++++++ include/linux/ioport.h | 4 ++ include/linux/kexec.h | 1 + kernel/kexec_file.c | 6 +-- kernel/resource.c | 81 +++++++++++++++++++++++++++++++++ 5 files changed, 134 insertions(+), 3 deletions(-) -- 2.30.2 _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
