Re: [PATCH v4 0/6] arm64 UEFI early FDT handling

[Ard Biesheuvel]

On 11 February 2016 at 12:42, Robert Richter
<robert.richter@xxxxxxxxxxxxxxxxxx> wrote:
> (+RobH and MarkR)
>
> On 09.02.16 15:35:42, Ard Biesheuvel wrote:
>> (+ Grant)
>>
>> On 9 February 2016 at 14:53, Robert Richter <rrichter@xxxxxxxxxxxxxxxxxx> wrote:
>> > From: Robert Richter <rrichter@xxxxxxxxxx>
>> >
>> > Reposting an updated version of this patches ported to 4.5-rc1. It is
>> > a followup to the version 3 from:
>> >
>> >  http://lkml.kernel.org/r/1442881288-13962-1-git-send-email-ard.biesheuvel@xxxxxxxxxx
>> >
>> > The series is essential for NUMA on arm64. Early FDT handling is
>> > required to make system topology data from firmware, esp. for cpus and
>> > memory available to the early boot process. Ganapat's numa patches
>> > depend on it. This series has been tested with his series v10 posted
>> > here:
>> >
>> >  http://lkml.kernel.org/r/1454407763-1017-1-git-send-email-gkulkarni@xxxxxxxxxxxxxxxxxx
>> >
>>
>> Hello Robert,
>>
>> This series does not reflect anymore what we think is the best way to
>> deal with memory nodes and memreserves on UEFI systems.
>> Please refer to this thread:
>> http://thread.gmane.org/gmane.linux.kernel.efi/6464
>>
>> As far as the memory nodes are concerned, if it is the best place to
>> store these NUMA annotations, then we should indeed preserve them, but
>> I think the discussion stalled without any conclusion having been
>> reached. As far as the /reserved-memory node is concerned, that one we
>> should really keep, so at least patch 6/6 of this series should be
>> replaced with something based on the series above.
>
> Ard,
>
> Mark R and Rob have agreed for numa dt binding for mem nodes. So do
> you think we can at least reuse parts of this series to solve the NUMA
> issue and try to find a solution for patch #6 which aligns with your
> alternative approach?
>

OK, if we are all in agreement that NUMA annotations belong in memory
nodes, which are otherwise ignored completely on UEFI systems, I am
fine with this as well.

However, we have to think about what it means if the memory nodes are
out of sync with the UEFI memory map, both on NUMA and ordinary
systems. I know very little about NUMA, but I could imagine that on
any UEFI system, the UEFI memory map remains authoritative, and memory
nodes are only used to annotate regions that are already known to
exist. Alternatively, some sanity check could be appropriate (such as
the one I proposed for the /reserved-memory node in the link above),
but we need to consider carefully how the firmware is supposed to
produce memory nodes and a UEFI memory map that are mutually
consistent.

I think we can replace 6/6 with the series above, i.e., honour the
allocations after establishing that the fixed allocations are either
still available, or entirely disjoint from what the UEFI memory map
describes.

-- 
Ard.