[PATCH 06/10] arm64: Update booting.txt to reserved-memory nodes

[Grant Likely]

On Fri, Oct 24, 2014 at 3:10 PM, Mark Rutland <mark.rutland at arm.com> wrote:
> On Fri, Oct 24, 2014 at 02:54:02PM +0100, Grant Likely wrote:
>> On Fri, Oct 24, 2014 at 1:18 PM, Mark Rutland <mark.rutland at arm.com> wrote:
>> > On Fri, Oct 24, 2014 at 12:04:00PM +0100, Grant Likely wrote:
>> >> On Fri, Oct 24, 2014 at 11:54 AM, Mark Rutland <mark.rutland at arm.com> wrote:
>> >> >
>> >> > On Fri, Oct 24, 2014 at 12:10:58AM +0100, Geoff Levand wrote:
>> >> > > Change any reference of device tree '/memreserve/' entries in the arm64
>> >> > > booting.txt to refer to 'reserved-memory nodes'.  Reserved-memory nodes
>> >> > > are the preferred method of specifying reserved memory.
>> >> >
>> >> > Per my comments on patch 5, I don't think this change is sufficient.
>> >> >
>> >> > However, we should probably update the document to allow reserved-memory
>> >> > nodes.
>> >> >
>> >> > On an unrelated note we probably need to work out how reserved-memory
>> >> > interacts with the UEFI memory map -- unmappable regions shouldn't be
>> >> > described by UEFI and I hope people don't use reserved-memory as a
>> >> > workaround for broken UEFI tables.
>> >>
>> >>
>> >> When booting with UEFI, the boot stub will clear out all memory nodes
>> >> and (should) clear out reserved regions so that the kernel can use the
>> >> UEFI memory map as authoritative.
>> >
>> > We clear memory nodes and memreserves currently.
>> >
>> > I was thinking about reserved-memory nodes (for CMA and such), which we
>> > don't currently clear.
>>
>> We should either clear them, or make sure that they will coexist
>> happily with the UEFI map. I can think of a few situations, like CMA,
>> where still having the reserved-memory node would be a good idea.
>
> My thinking would be that reservations which the kernel could choose to
> ignore for whatever reason and use for general allocation (e.g. CMA)
> make sense, but anything else is nonsense if it overlaps with available
> memory in the UEFI memory map -- it shouldn't have been there to begin
> with.
>
> I don't know what the best thing to do in that case is. I'd like to
> explode very loudly during bringup to get vendors to fix their UEFI
> tables, but in the long run we might just have to reconcile the two and
> align with the most stringent requirement. Good luck getting another OS
> working in that case...

On ACPI platforms this is a non-issue. On UEFI+FDT platforms there are
unlikely to be any other operating systems significantly affected by
this.

g.