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
