Hi, (sorry for the late response) On 06/11/2020 18:46, Nicolas Saenz Julienne wrote: > On Thu, 2020-11-05 at 16:11 +0000, James Morse wrote:>> We also depend on this when skipping the checksum code in purgatory, which can be >> exceedingly slow. > > This one I don't fully understand, so I'll lazily assume the prerequisite is > the same WRT how memory is mapped. :) The aim is its never normally mapped by the kernel. This is so that if we can't get rid of the secondary CPUs (e.g. they have IRQs masked), but they are busy scribbling all over memory, we have a rough guarantee that they aren't scribbling over the kdump kernel. We can skip the checksum in purgatory, as there is very little risk of the memory having been corrupted. > Ultimately there's also /sys/kernel/kexec_crash_size's handling. Same > prerequisite. Yeah, this lets you release PAGE_SIZEs back to the allocator, which means the marked-invalid page tables we have hidden there need to be PAGE_SIZE mappings. Thanks, James > Keeping in mind acpi_table_upgrade() and unflatten_device_tree() depend on > having the linear mappings available. I don't see any simple way of solving > this. Both moving the firmware description routines to use fixmap or correcting > the linear mapping further down the line so as to include kdump's regions, seem > excessive/impossible (feel free to correct me here). I'd be happy to hear > suggestions. Otherwise we're back to hard-coding the information as we > initially did. > > Let me stress that knowing the DMA constraints in the system before reserving > crashkernel's regions is necessary if we ever want it to work seamlessly on all > platforms. Be it small stuff like the Raspberry Pi or huge servers with TB of > memory.
