From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Rutland Subject: Re: [PATCH] efi/libstub/arm*: Set default address and size cells values for an empty dtb Date: Tue, 7 Feb 2017 19:37:12 +0000 Message-ID: <20170207193712.GJ26173@leverpostej> References: <1486490390-25251-1-git-send-email-jhugo@codeaurora.org> <20170207181554.GD26173@leverpostej> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Timur Tabi Cc: Jeffrey Hugo , Sameer Goel , linux-efi@vger.kernel.org, "linux-arm-kernel@lists.infradead.org" List-Id: linux-efi@vger.kernel.org On Tue, Feb 07, 2017 at 01:24:53PM -0600, Timur Tabi wrote: > On Tue, Feb 7, 2017 at 12:15 PM, Mark Rutland wrote: > > > >> In cases where a device tree is not provided (ie ACPI based system), an > >> empty fdt is generated by efistub. Sets the address and size cell values > >> in a generated fdt to support 64 bit addressing. > >> > >> This enables kexec/kdump on Qualcomm Technologies QDF24XX platforms as those > >> utilities will read the address/size values from the fdt, and such values > >> may exceed the range provided by the 32 bit default. > > > > The description here doesn't state why this is a problem for ACPI. > > The patch description could use some work. It's a problem for ACPI > because EFI-based systems call typically fdt_create_empty_tree(), > which is where the problem lies. > > The bug is that fdt_create_empty_tree() literally creates an empty > tree. By default if a node is missing #address-cells and #size-cells > properties, then it's assume that both values are equal to 1, i.e. > 32-bit addresses. Sure, I understand this. > When update_fdt() in drivers/firmware/efi/libstub/fdt.c creates an > empty tree, it then proceeds to inject 64-bit addresses into that > tree. When kdump tries to process the address properties, it reads > the wrong values because it thinks they are all 32-bit addresses. This is *not* true. The EFI stub only injects values which are always defined to be 64 bits in width. In Takahiro-san's arm64/kdump branch, the userspace kdump code doesn't parse properties out of the DT. In fact, it simply assumes that the kdump-specific properties always have 64 bits of address, and 64-bits of size, and inserts these sized accordingly. The kdump kernel, however, tries to use /#address-cells and /#size-cells. That is where I assume things go wrong. There is no upstream kdump code for arm64. Thanks, Mark.