On 01/19/2016 10:43 AM, Dave Young wrote: > On 01/18/16 at 07:26pm, AKASHI Takahiro wrote: >> On 01/16/2016 05:16 AM, Mark Rutland wrote: >>> On Fri, Jan 15, 2016 at 07:18:38PM +0000, Geoff Levand wrote: >>>> From: AKASHI Takahiro <takahiro.akashi at linaro.org> >>>> >>>> This patch adds arch specific descriptions about kdump usage on arm64 >>>> to kdump.txt. >>>> >>>> Signed-off-by: AKASHI Takahiro <takahiro.akashi at linaro.org> >>>> --- >>>> Documentation/kdump/kdump.txt | 23 ++++++++++++++++++++++- >>>> 1 file changed, 22 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt >>>> index bc4bd5a..36cf978 100644 >>>> --- a/Documentation/kdump/kdump.txt >>>> +++ b/Documentation/kdump/kdump.txt >>>> @@ -18,7 +18,7 @@ memory image to a dump file on the local disk, or across the network to >>>> a remote system. >>>> >>>> Kdump and kexec are currently supported on the x86, x86_64, ppc64, ia64, >>>> -s390x and arm architectures. >>>> +s390x, arm and arm64 architectures. >>>> >>>> When the system kernel boots, it reserves a small section of memory for >>>> the dump-capture kernel. This ensures that ongoing Direct Memory Access >>>> @@ -249,6 +249,20 @@ Dump-capture kernel config options (Arch Dependent, arm) >>>> >>>> AUTO_ZRELADDR=y >>>> >>>> +Dump-capture kernel config options (Arch Dependent, arm64) >>>> +---------------------------------------------------------- >>>> + >>>> +1) The maximum memory size on the dump-capture kernel must be limited by >>>> + specifying: >>>> + >>>> + mem=X[MG] >>>> + >>>> + where X should be less than or equal to the size in "crashkernel=" >>>> + boot parameter. Kexec-tools will automatically add this. >>> >>> >>> This is extremely fragile, and will trivially fail when the kernel can >>> be loaded anywhere (see [1]). >> >> As I said before, this restriction also exists on arm, but I understand >> that recent Ard's patches break it. >> >>> We must explicitly describe the set of regions the crash kernel may use >>> (i.e. we need base and size). NAK in the absence of that. >> >> There seem to exist several approaches: >> (a) use a device-tree property, "linux,usable-memory", in addition to "reg" >> under "memory" node >> (b) use a kernel's early parameter, "memmap=nn[@#$]ss" >> >> Power PC takes (a), while this does not work on efi-started kernel >> because dtb has no "memory" nodes under efi. >> X86 takes (b). If we take this, we will need to overwrite a weak >> early_init_dt_add_memory(). > > X86 takes another way in latest kexec-tools and kexec_file_load, that is > recreating E820 table and pass it to kexec/kdump kernel, if the entries > are over E820 limitation then turn to use setup_data list for remain > entries. Thanks. I will visit x86 code again. > I think it is X86 specific. Personally I think device tree property is > better. Do you think so? -Takahiro AKASHI > > Thanks > Dave >
