Re: makedumpfile: get_max_mapnr() from ELF header problem

[Michael Holzheu <holzheu@linux.vnet.ibm.com>]

On Tue, 11 Mar 2014 06:22:41 +0000
Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp> wrote:

> >On Mon, 3 Mar 2014 03:11:23 +0000
> >Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp> wrote:
> >The tools do a physical memory detection and that defines the range
> >of memory to be dumped and also defines the memory chunks for the
> >ELF header.
> 
> makedumpfile is designed for kdump, this means it relies on dependable ELF
> headers. If we support such an incorrect ELF header, makedumpfile has to get
> the actual memory map from vmcore (but I have no ideas how to do it now) and
> re-calculate all PT_LOAD regions with it. It sounds too much work for
> irregular case, I don't plan to take care of it now.

Ok, fair.
 
> >And I think we are not the only ones that have this problem. For example,
> >the KVM virsh dump probably also has that problem.
> 
> virsh dump seems to have the same issue as you said, but I suppose qemu
> developers don't worry about that because they are developing an original
> way to dump guest's memory in kdump-compressed format as "dump-guest-memory"
> command. It seems that they know such case is out of the scope of makedumpfile.

Even if they create a kdump-compressed format dump, they (probably) do not
filter while dumping. Therefore for large dumps post-processing with
makedumpfile could still make sense, e.g. for transfering the dumps. 

Because qemu is not aware of kernel parameters this will also fail when "mem="
has been used.

Michael


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec