On Tue, 11 Mar 2014 06:22:41 +0000 Atsushi Kumagai <kumagai-atsushi at mxc.nes.nec.co.jp> wrote: > >On Mon, 3 Mar 2014 03:11:23 +0000 > >Atsushi Kumagai <kumagai-atsushi at 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
