Hi Will, On Tue, 18 May 2021 at 17:19, Will Deacon <will@xxxxxxxxxx> wrote: > > [Fixing Bhupesh's email address] > > On Thu, Apr 29, 2021 at 02:35:31PM +0100, 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. And of course, > > our LPI tables are only reserved using the resource tree, leading to > > the aforementioned stamping. Similar things could happen with ACPI > > tables as well. > > > > 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. > > Bhupesh, since you've been involved with kexec file on arm64 before, please > could you take a look at these patches? Thanks for adding me in Cc. Yes, I will look and test these patches asap. Regards, Bhupesh _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
