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

[qiaonuohan]

At 2012-8-8 21:26, Dave Anderson wrote:
>
>
> ----- 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.

I see. And I reworked the patches to treat qemu memory dump as kdump.
>
>>   >  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?

Yes, that's right. To see dump image from the 2nd kernel's view,
phys_base should be set.

P.S.
I will suspend the work for about one week because of personal affairs.

>
> Dave
>
> --
> Crash-utility mailing list
> Crash-utility at redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
>
>


-- 
--
Regards
Qiao Nuohan


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-display-registers-stored-in-qemu-note-section.patch
Type: text/x-patch
Size: 11827 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20120810/faa4430a/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-add-support-to-qemu-memory-dump.patch
Type: text/x-patch
Size: 4843 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20120810/faa4430a/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-support-core-dump-file-when-kdump-is-operating.patch
Type: text/x-patch
Size: 8768 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20120810/faa4430a/attachment-0002.bin>