[PATCH 18/19] arm64: kdump: update a kernel doc

[Mark Rutland]

Ard, Ganapatrao, the below is something we need to consider for the
combination of the NUMA & kexec approaches. It only becomes a problem
if/when we preserve DT memory nodes in the presence of EFI, though it
would be nice to not box ourselves into a corner.

On Wed, Jan 20, 2016 at 12:02:58PM +0000, Mark Rutland wrote:
> On Wed, Jan 20, 2016 at 02:25:07PM +0900, AKASHI Takahiro wrote:
> > On 01/19/2016 11:01 PM, Mark Rutland wrote:
> > >For NUMA topology in !ACPI kernels, we might need to also retain and
> > >parse memory nodes, but only for toplogy information. The kernel would
> > >still only use memory as described by the EFI memory map.
> > >
> > >There's a horrible edge case I've spotted if performing a chain of
> > >cross-endian kexecs: LE -> BE -> LE, as the BE kernel would have to
> > >respect the EFI memory map so as to avoid corrupting it for the
> > >subsequent LE kernel. Other than this I believe everything should just
> > >work.
> > 
> > BE kernel doesn't support UEFI yet and cannot access UEFI memmap table. So,
> > for LE -> BE, we don't use a dtb generated from /sys/firmware/fdt (or /proc/device-tree)
> > (as in the case of LE -> LE) and require users to provide a dtb file explicitly.
> 
> As I mentioned above, the problem exists when memory nodes also exist
> (for describing NUMA topology). In that case the BE kernel would try to
> use the information from the memory nodes.
> 
> > For BE -> LE, BE kernel doesn't know wther UEFI memmap table is available or not
> > and so use the same (explicitly-provided) dtb (as LE -> LE in !UEFI)
> 
> See above. The problem I imagine is:
> 
> LE kernel - uses EFI mmap, takes NUMA information from DT memory nodes
> 
>     v       kexec
> 
> BE kernel - uses DT memory nodes
>           - clobbers EFI runtime regions as it sees them as available
> 
>     v       kexec
> 
> LE kernel - uses EFI mmap, takes NUMA information from DT memory nodes
>           - tries to call EFI runtime services, and explodes.

I'm not really sure what the best approach is here, but I thought that
it would be good to raise awareness of the edge-case.

Mark.