On Wed, Jan 20, 2016 at 03:59:08PM +0100, Ard Biesheuvel wrote: > On 20 January 2016 at 13:36, Mark Rutland <mark.rutland at arm.com> wrote: > > 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. > > > > I think we should simply allow the BE kernel to deal with a UEFI > memory map. It only involves a bit of byte swapping (which I already > implemented at some point) > > It would require some minor refactoring to make the UEFI init code > separate from all the other bits, but I don't see any major issues > here Ok. I had assumed that getting the BE kernel to deal with the UEFI memory map would be a bit more involved. I'm happy to be proven wrong. :) Thanks, Mark.
