makedumpfile: question about memory hole

[Atsushi Kumagai]

On Tue, 19 Mar 2013 11:42:20 +0900 (JST)
HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com> wrote:

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

Oh, I understand your question correctly now.

When Ohmichi-san wrote this code, he thought the page which include
memory hole isn't be used. This came from the fact that the basic
unit of memory management is *page*, but there is no detailed
investigation. 

So, if there is any case where pfn:N is actually used, this statement
should be removed. Maybe, does this question come from an idea of such
cases ?


Thanks
Atsushi Kumagai