From: Atsushi Kumagai <kumagai-atsushi@xxxxxxxxxxxxxxxxx> 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
