At 2012-8-8 2:59, Dave Anderson wrote:
Anyway, it was surprising to note is that the two dumpfiles can already
can be read with no problem by the crash utility -- with no additional
patches to support it. The crash utility just thinks that it's a kdump
with some unknown "QEMU" ELF notes:
That's right. The formats are extremely similar, except the qemu note
section.
I should have suggested moving one of the currently-existing
pc->flags bits into
pc->flags2, and keeping all the dumpfile types in pc->flags.
Or at
least create a
I think it's a better choice. But encountering a new type of dump file,
creating a patch used to move bits in pc->flags can easily put things
into a mess. Why not use a new flag only used to keep dumpfile types?
new macro to replace all the usages of "(pc->flags&
MEMORY_SOURCES)".
My mistake, Qian -- sorry about that...
But -- it seems that we can just leave the dumpfile type as a
"KDUMP_ELF32/KDUMP_ELF64",
and then based upon the existence of a "QEMU" note, just
set a
QEMU_MEM_DUMP pc->flags2
bit that can be used everywhere that you're interested in
accessing
the "QEMU"
notes/registers section? Wouldn't that be far simpler?
Treat it as a kdump files seems cool to me. The only problem is I still
need to distinguish kdump and qemu memory dump, not only using qemu note
section, but also the first 640K is special(when doing qemu memory dump,
the second kernel is working).
Dave
--
--
Regards
Qiao Nuohan