Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest

[Alexander Graf]

Am 10.10.2011 um 08:52 schrieb Jan Kiszka <address@hidden>:

> On 2011-10-10 04:21, Wen Congyang wrote:
>> At 10/09/2011 06:23 PM, Richard W.M. Jones Write:
>>> On Sun, Oct 09, 2011 at 10:49:57AM +0200, Jan Kiszka wrote:
>>>> As explained in the other replies: It is way more future-proof to use an
>>>> interface for this which was designed for it (remote gdb) instead of
>>>> artificially relaxing reasonable constraints of the migration mechanism
>>>> plus having to follow that format with the post-processing tool.
>>> 
>>> Any interface that isn't "get this information off my production
>>> server *now*" so that I can get the server restarted, and send it to
>>> an expert to analyse -- is a poor interface, whether it was designed
>>> like that or not.  Perhaps we don't have the right interface at all,
>>> but remote gdb is not it.
>> 
>> What about the following idea?
>> 
>> Introduce a new monitor command named dump, and this command accepts a 
>> filename.
>> We can use almost all migration's code. We use this command to dump guest's
>> memory, so there is no need to check whether the guest has a unmigratable 
>> device.
> 
> I do not want to reject this proposal categorically, but I would like to
> see the gdb path fail /wrt essential requirements first. So far I don't
> see it would.

Through gdb you access virtual address space, whilein this case you really want 
physical.

All you need to create a core file is a memory dump and a register dump. For 
registers, gdb sounds like a good interface. For memory, why not just use 
pmemsave? Maybe add a monitor/qmp command that tells you all ram regions, so 
pmemsave can be invoked intelligently.

The alternative to all this is obviously an in-qemu 'core' command that creates 
core files inside of qemu. That's where I think it really belongs to. Libvirt 
is a management tool stack, not a "I don't like to work on qemu code so I push 
code to the layer on top" mesh of things. Or at least that's how it's really 
supposed to be :).


Alex

>