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

[Dave Young]

On 10/22/15 at 06:57pm, AKASHI Takahiro wrote:
> (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.

If this is the case there must be somewhere else one can pass memory infomation
to kernel, the booting.txt should be updated?

kexec as a boot loader need use same method as the 1st kernel boot loader.

> 
> >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.

For example the elf headers range, you reserved them in kdump kernel code,
but kexec-tools can do that early if it can provides all memory info to 2nd
kernel. Ditto for mark all the memory ranges 1st kernel used as reserved.

Thanks
Dave