[PATCH 13/16] arm64: kdump: add kdump support

[AKASHI Takahiro]

(added Ard to Cc.)

On 10/22/2015 02:15 PM, Dave Young wrote:
> On 10/22/15 at 01:29pm, AKASHI Takahiro wrote:
>> Hi Dave,
>>
>> Thank you for your comment.
>>
>> On 10/22/2015 12:25 PM, Dave Young wrote:
>>> Hi, AKASHI,
>>>
>>> On 10/19/15 at 11:38pm, Geoff Levand wrote:
>>>> From: AKASHI Takahiro <takahiro.akashi at linaro.org>
>>>>
>>>> On crash dump kernel, all the information about primary kernel's core
>>>> image is available in elf core header specified by "elfcorehdr=" boot
>>>> parameter. reserve_elfcorehdr() will set aside the region to avoid any
>>>> corruption by crash dump kernel.
>>>>
>>>> Crash dump kernel will access the system memory of primary kernel via
>>>> copy_oldmem_page(), which reads one page by ioremap'ing it since it does
>>>> not reside in linear mapping on crash dump kernel.
>>>> Please note that we should add "mem=X[MG]" boot parameter to limit the
>>>> memory size and avoid the following assertion at ioremap():
>>>> 	if (WARN_ON(pfn_valid(__phys_to_pfn(phys_addr))))
>>>> 		return NULL;
>>>> when accessing any pages beyond the usable memories of crash dump kernel.
>>>
>>> How does kexec-tools pass usable memory ranges to kernel? using dtb?
>>> Passing an extra mem=X sounds odd in the design. Kdump kernel should get
>>> usable ranges and hanle the limit better than depending on an extern kernel
>>> param.
>>
>> Well, regarding "depending on an external kernel param,"
>> - this limitation ("mem=") is compatible with arm(32) implementation although
>>    it is not clearly described in kernel's Documentation/kdump/kdump.txt.
>> - "elfcorehdr" kernel parameter is mandatory on x86 as well as on arm/arm64.
>>    The parameter is explicitly generated and added by kexec-tools.
>>
>> Do I miss your point?
>
> Arm previously use atag_mem tag for memory kernel uses, with dtb, Booting.txt
> says: The boot loader must pass at a minimum the size and location of the
> system memory
>
> In arm64 booting.txt, it does mentions about dtb but without above sentence.
>
> So if you are using dtb to pass memory I think the extra mem= should be not
> necessary unless there's other limitations dtb can not been used.

I would expect comments from arm64 maintainers here.

In my old implementation, I added "usablemem" attributes, along with "reg," to
"memory" nodes in dtb to specify the usable memory region on crash dump kernel.

But I removed this feature partly because, on uefi system, uefi might pass
no memory information in dtb.

> One thing I'm confused is mem= only pass the memory size, where does you pass
> the start addresses?

In the current arm64 implementation, any regions below the start address will
be ignored as system ram.

> What if there's multiple sections such as some reserved
> ranges 2nd kernel also need?

My patch utilizes only a single contiguous region of memory as system ram.
One exception that I notice is uefi's runtime data. They will be ioremap'ed separately.

Please let me know if there is any other case that should be supported.

Thanks,
-Takahiro AKASHI

> Thanks
> Dave
>