Re: [PATCH v12 1/5] efi: ARM/arm64: ignore DT memory nodes instead of removing them

From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	David Daney <ddaney.cavm@gmail.com>,
	Rob Herring <robh+dt@kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	Pawel Moll <pawel.moll@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Kumar Gala <galak@codeaurora.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Frank Rowand <frowand.list@gmail.com>,
	Grant Likely <grant.likely@linaro.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Matt Fleming <matt@codeblueprint.co.uk>,
	"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
	Ganapatrao Kulkarni <gkulkarni@caviumnetworks.com>,
	Robert Richter <rrichter@cavium.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Daney <david.daney@cavium.com>
Subject: Re: [PATCH v12 1/5] efi: ARM/arm64: ignore DT memory nodes instead of removing them
Date: Tue, 23 Feb 2016 13:20:10 +0100	[thread overview]
Message-ID: <CAKv+Gu8fOKqLrnbre7sHko+hPd3wq_O6U5Ev27tN3zEc7W8Mww@mail.gmail.com> (raw)
In-Reply-To: <20160223121648.GI3966@arm.com>

On 23 February 2016 at 13:16, Will Deacon <will.deacon@arm.com> wrote:
> On Tue, Feb 23, 2016 at 11:58:05AM +0000, Mark Rutland wrote:
>> On Mon, Feb 22, 2016 at 05:58:19PM -0800, David Daney wrote:
>> > From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> >
>> > There are two problems with the UEFI stub DT memory node removal
>> > routine:
>> > - it deletes nodes as it traverses the tree, which happens to work
>> >   but is not supported, as deletion invalidates the node iterator;
>> > - deleting memory nodes entirely may discard annotations in the form
>> >   of additional properties on the nodes.
>> >
>> > Since the discovery of DT memory nodes occurs strictly before the
>> > UEFI init sequence, we can simply clear the memblock memory table
>> > before parsing the UEFI memory map. This way, it is no longer
>> > necessary to remove the nodes, so we can remove that logic from the
>> > stub as well.
>>
>> This is a little bit scary, but I guess this works.
>>
>> My only concern is that when we get kexec, a subsequent kernel must also
>> have EFI memory map support, or things go bad for the next EFI-aware
>> kernel after that (as things like the runtime services may have been
>> corrupted by the kernel in the middle). It's difficult to fix the
>> general case later.
>>
>> A different option would be to support status="disabled" for the memory
>> nodes, and ignore these in early_init_dt_scan_memory. That way a kernel
>> cannot use memory without first having parsed the EFI memory map, and we
>> can still get NUMA info from the disabled nodes.
>
> So in that case, the middle, non-EFI kernel would fail to boot?
> Realistically, once you've kexec'd a non-EFI payload, I don't think you
> can rely on the EFI state remaining intact for future EFI applications.
>
> Is this really something we should be trying to police in the kernel?
>

Well, we could add entries to /reserved-memory in the stub for all the
regions UEFI cares about, that would probably be sufficient to fix
this case.