[Crash-utility] [PATCH] add support to "virsh dump-guest-memory"(qemu memory dump)

[Dave Anderson]

----- Original Message -----
> 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?

Yes, that's probably a better idea.  When the next "real" dumpfile type
comes along, perhaps we can go that route.

>  > 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).

Right, and you will be able to set the new QEMU_MEM_DUMP flag very early 
on during the dumpfile determination phase so that later you will have 
that knowledge at hand later on when you want to deal with the notes.

With respect to the "second-kernel" issue, I would presume that you would
have to use the currently-existing "--machdep phys_base=<physaddr>" capability
for x86_64?

Dave