On Tue, 06 Nov 2018 19:01:51 +0000, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: > > On 6 November 2018 at 19:27, Marc Zyngier <marc.zyngier@xxxxxxx> wrote: > > Hi Ard, > > > > On 06/11/18 11:37, Ard Biesheuvel wrote: > >> This series addresses the kexec/kdump crash on arm64 system with many CPUs > >> that was reported by Bhupesh. > >> > >> Patches #1 and #2 fix the actual crash. Patches #3 and #4 optimize the > >> EFI persistent memreserve infrastructure so that fewer memblock reservations > >> are required. > >> > >> Ard Biesheuvel (4): > >> arm64: memblock: don't permit memblock resizing until linear mapping > >> is up > >> efi/arm: defer persistent reservations until after paging_init() > >> efi: permit multiple entries in persistent memreserve data structure > >> efi: reduce the amount of memblock reservations for persistent > >> allocations > >> > >> arch/arm/kernel/setup.c | 1 + > >> arch/arm64/kernel/setup.c | 1 + > >> arch/arm64/mm/init.c | 2 - > >> arch/arm64/mm/mmu.c | 2 + > >> drivers/firmware/efi/efi.c | 59 ++++++++++++++------ > >> drivers/firmware/efi/libstub/arm-stub.c | 2 +- > >> include/linux/efi.h | 23 +++++++- > >> 7 files changed, 68 insertions(+), 22 deletions(-) > > > > I've just given these patches a go a a TX2 box (one of the 224 CPU > > ones...), and kexec worked just fine (v4.20-rc1 vanilla didn't manage to > > kexec on this box). > > > > There seem to be some additional userspace patches that are required for > > the ACPI tables not to be corrupted in the secondary kernel, but that's > > an orthogonal issue. > > > > Feel free to add > > > > Tested-by: Marc Zyngier <marc.zyngier@xxxxxxx> > > > > Thanks Marc. > > Any thoughts on whether patches #3 and #4 should be included as fixes? > I'm leaning towards yes. They certainly massively reduce the number of list entries, and probably help reducing the overhead. I'd be inclined to merge them as well. Thanks, M. -- Jazz is not dead, it just smell funny.
