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:13:20 +0000 Message-ID: <20170207191320.GI26173@leverpostej> References: <1486490390-25251-1-git-send-email-jhugo@codeaurora.org> <1f47fcdd-c5d8-4082-70a3-ca9b1746d7ca@codeaurora.org> <20170207190113.GG26173@leverpostej> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-efi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Jeffrey Hugo Cc: Sameer Goel , "linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , Ard Biesheuvel List-Id: linux-efi@vger.kernel.org On Tue, Feb 07, 2017 at 12:07:56PM -0700, Jeffrey Hugo wrote: > On 2/7/2017 12:01 PM, Mark Rutland wrote: > >On Tue, Feb 07, 2017 at 11:54:55AM -0700, Jeffrey Hugo wrote: > >>On 2/7/2017 11:12 AM, Ard Biesheuvel wrote: > >>>On 7 February 2017 at 17:59, Jeffrey Hugo wrote: > >>>>From: Sameer Goel > >>>> > >>>>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. > >>>> > >>> > >>>As far as I know, those properties are explicitly associated with the > >>>'reg' properties of subordinate nodes. So which nodes are we talking > >>>about here? Are we producing an incorrect DT by not setting these? Or > >>>is this simply a convenience to work around bugs in the tooling? > >> > >>I think we are producing an incorrect DT, in some instances. > >> > >>So we are starting from the same baseline, this is specific to ACPI > >>systems, as an ACPI system won't have a DT from the bootloader. DT > >>based systems will already have a DT from the bootloader which is > >>assumed to be correct. On ACPI systems without a DT, efistub > >>generates a default one. > >> > >>That default is assumed to be for a 32-bit system. The cell width > >>defaults to 1, which is 4 bytes. You cannot represent a 64-bit > >>value in that instance. > >> > >>What happens is that kexec inserts properties into the fdt which > >>contain the start address and size on the crash kernel. On our > >>system, the start address is a 64-bit value, and while its not the > >>case today, I see no reason why size could not also be a 64-bit > >>value. However the values that are inserted into the fdt are > >>governed by the address and size cell values already present in the > >>fdt. > >> > >>Kexec attempts to insert these values in the fdt. The fdt only > >>accepts 32-bit values, so it truncates what is put in. Then later > >>kexec/kdump read the values from the fdt, and get garbage. > > > >I take it this is specific to the kdump properties? > > > >I can't immediately see what would matter for the !kdump case. > >properties inserted under /chosen are not truncated? > > The kexec/kdump properties are added under /chosen, therefore yes, > properties added under /chosen are truncated, per our observations. Sorry for the dodgy (and confusing) reply above. What I was trying to ask was does this *only* affect kdump properties? I note that kdump is not yet upstream for arm64. Or are there regular kexec properties that this affects? Or !kdump && !kexec properties? Can you please enumerate the set of properties for which this matters? Thanks, Mark.