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

[Wang Nan]

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
>