[PATCH Resend] ARM: kdump: makes second kernel use strict pfn_valid

[Wang Nan]

Hi Will,

What's your opinion about my explanation?

Thanks!

On 2014/5/20 11:22, Wang Nan wrote:
> On 2014/5/20 0:09, Will Deacon wrote:
>> On Mon, May 19, 2014 at 02:54:03AM +0100, Wang Nan wrote:
>>> When SPARSEMEM and CRASH_DUMP both selected, simple pfn_valid prevents
>>> the second kernel ioremap first kernel's memory if the address falls
>>> into second kernel section. This limitation requires the second kernel
>>> occupies a full section, and elfcorehdr must resides in another section.
>>>
>>> This patch makes crash dump kernel use strict pfn_valid, removes such
>>> limitation.
>>>
>>> For example:
>>>
>>>   For a platform with SECTION_SIZE_BITS == 28 (256MiB) and
>>>   crashkernel=128M at 0x28000000 in kernel cmdline, the second
>>>   kernel is loaded at 0x28000000. Kexec puts elfcorehdr at
>>>   0x2ff00000, and passes 'elfcorehdr=0x2ff00000 mem=130048K' to
>>>   second kernel. When second kernel start, it tries to use
>>>   ioremap to retrive its elfcorehrd. In this case, elfcodehdr is at the
>>>   same section of the second kernel, pfn_valid will recongnize
>>>   the page as valid, so ioremap will refuse to map it.
>>
>> So isn't the issue here that you're passing an incorrect mem= parameter
>> to the crash kernel?
>>
> 
> mem= parameter is generated by kexec-tools according to /proc/iomem, it is the size
> of reserved memory minus 1MiB. So I think what you mean is I passing an incorrect
> crashkernel= parameter?
> 
> I'll explain limitations on crash kernel reserved memory in the case of SPARSEMEM
> enabled, and show how *impractical* the 'correct' crashkernel will be.
> 
> Use realview board for example.
> 
> Limitation 1: crash kernel reservation kernel must be aligned with 0x08000000 (128MiB).
> 
>   This is because zImage determine final kernel address by (pc & 0xf8000000). If,
>   for example, set crashkernel=64M at 0x29000000, then the second kernel itself
>   overwrites first kernel's memory. We'll lost some memory in /proc/vmcore.
> 
> Limitation 2: crash kernel must resides in different section with the first kernel.
> 
>   This is because the second kernel use ioremap for accessing first kernel's memory,
>   and arm prevent a valid pfn be ioremapped. Which means a whole section must be reserved
>   for the secton kernel. On realview, which is 256MiB.
> 
> Limitation 3: the last 1MiB of reserved memory must be ioremappable.
> 
>   This is because the second kernel depeneds kexec-tools passing an elfheader as
>   'elfcorehdr' to instructs it generating /proc/vmcore. See fs/proc/vmcore.c. Kexec-tools
>   simply uses the last 1MiB for it. The second kernel use ioremap to access it, force
>   the header be put in another section.
> 
> In realview board, the only possible correct setting should be 'crashkernel=257M at 0x20000000'.
> However, realview has only 1GiB memory, crash kernel consumes a quarter plus 1MiB. In addition, even
> set this parameter, crash kernel is still unusable because:
> 
>   crashkernel reservation failed - memory is in use (0x20000000)
> 
>> Will
>>
> 
> 
> 
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>