On 2/7/2017 12:13 PM, Mark Rutland wrote:
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?
"linux,elfcorehdr" and "linux,usable-memory-range"
We are not aware of !kdump && !kexec properties where this is an issue.
Thanks,
Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Jeffrey Hugo
Qualcomm Datacenter Technologies as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
--
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
