makedumpfile: question about memory hole

[HATAYAMA Daisuke]

From: Atsushi Kumagai <kumagai-atsushi at mxc.nes.nec.co.jp>
Subject: Re: makedumpfile: question about memory hole
Date: Tue, 19 Mar 2013 10:41:37 +0900

> On Fri, 15 Mar 2013 09:31:46 +0900 (JST)
> HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com> wrote:

>> What I don't understand well is that the part here:
>> 
>>                 pfn_start = paddr_to_pfn(phys_start);
>>                 pfn_end   = paddr_to_pfn(phys_end);
>> 
>>                 if (!is_in_segs(pfn_to_paddr(pfn_start)))
>>                         pfn_start++;
>> 
>> phys_start and pfn_to_paddr(pfn_start) should belong to the same page
>> frame, so I suspect the pfn_start should be included in vmcore.
>> 
>> Looking into kexec-tool side, I don't see additional modification made
>> to phys_start after it's parsed from /proc/iomem or counterpart on EFI
>> interface. Is there any assumption about memory holes behind kernel?
> 
> Here is a PT_LOAD segment of ia64 machine which I actually use:
> 
>   Type           Offset             VirtAddr           PhysAddr
>                  FileSiz            MemSiz              Flags  Align
> [...]
>   LOAD           0x000000015fd0b490 0xe0000040ffda5000 0x00000040ffda5000
>                  0x000000000005a000 0x000000000005a000  RWE    0
> 
> In this case, pfn_to_paddr(pfn_start) is aligned to 0x40ffda4000 
> because the page size is 16KiB, and this address is out of PT_LOAD
> segment.
> 
>          phys_start
>          = 0x40ffda5000                        
>             |------------- PT_LOAD ----------------
>      ----+----------+----------+----------+--------
>          |   pfn:N  |  pfn:N+1 | pfn:N+2  |  ...
>      ----+----------+----------+----------+--------
>          |
>    pfn_to_paddr(pfn:N)
>    = 0x40ffda4000
> 
> The statement you said is for care the case that phys_start isn't aligned
> with the page size.
> 
> BTW, I'll add a comment to explain this intention into here.

Thanks for the pictorial explanation. It's easy to understand.

Still I think pfn:N should be included in vmcore. The current
implementation drops [0x40ffda5000, 0x40ffda8000] that is contained in
the PT_LOAD. Or, the range must be hole or other kinds of unnecessary
memory from some kernel-side assumption?

Thanks.
HATAYAMA, Daisuke