From: Michael Holzheu <holzheu@linux.vnet.ibm.com>
To: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
Cc: "d.hatayama@jp.fujitsu.com" <d.hatayama@jp.fujitsu.com>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>
Subject: Re: makedumpfile: get_max_mapnr() from ELF header problem
Date: Tue, 11 Mar 2014 12:35:45 +0100 [thread overview]
Message-ID: <20140311123545.30bc23cf@holzheu> (raw)
In-Reply-To: <0910DD04CBD6DE4193FCF86B9C00BE971F4AFE@BPXM01GP.gisp.nec.co.jp>
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
next prev parent reply other threads:[~2014-03-11 11:36 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-28 12:41 makedumpfile: get_max_mapnr() from ELF header problem Michael Holzheu
2014-03-03 3:11 ` Atsushi Kumagai
2014-03-03 9:44 ` Michael Holzheu
2014-03-11 6:22 ` Atsushi Kumagai
2014-03-11 11:35 ` Michael Holzheu [this message]
2014-03-12 4:15 ` HATAYAMA Daisuke
2014-03-12 6:01 ` Atsushi Kumagai
2014-03-12 16:18 ` Michael Holzheu
2014-03-14 8:54 ` Atsushi Kumagai
2014-03-14 14:19 ` Michael Holzheu
2014-03-19 7:14 ` Atsushi Kumagai
2014-03-19 18:29 ` Michael Holzheu
2014-03-20 10:23 ` Michael Holzheu
[not found] ` <20140319180903.2c6e2b72@holzheu>
2014-03-25 1:14 ` Atsushi Kumagai
2014-03-25 15:24 ` Michael Holzheu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140311123545.30bc23cf@holzheu \
--to=holzheu@linux.vnet.ibm.com \
--cc=d.hatayama@jp.fujitsu.com \
--cc=kexec@lists.infradead.org \
--cc=kumagai-atsushi@mxc.nes.nec.co.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.