On 10/29/2015 03:40 PM, Dave Young wrote:
Hi, AKASHI
On 10/29/15 at 02:55pm, AKASHI Takahiro wrote:
Dave,
On 10/23/2015 06:50 PM, Dave Young wrote:
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 <[email protected]>
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.
It seems to me that the issue you mentioned here is totally independent
from "mem=" issue, isn't it?
(and "elfcorehdr=" is a common way for crash dump kernel to know the region.)
Hmm, I did not talked about the eflcorehdr=, I means the code to reserve the
memory ranges elfcorehdr is using.
So how does it relate to "mem=" issue?
-Takahiro AKASHI
Thanks
Dave
-Takahiro AKASHI
Thanks
Dave
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
