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 <jhugo@xxxxxxxxxxxxxx> wrote: > >>>>From: Sameer Goel <sgoel@xxxxxxxxxxxxxx> > >>>> > >>>>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. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
