Re: [Qemu-devel] [RFC][PATCH 09/15] introduce a new monitor command 'dump' to dump guest's memory

[Wen Congyang]

At 01/31/2012 01:19 AM, Eric Blake Wrote:
> On 01/29/2012 10:36 PM, Wen Congyang wrote:
>>>> +++ b/hmp-commands.hx
>>>> @@ -828,6 +828,22 @@ new parameters (if specified) once the vm migration 
>>>> finished successfully.
>>>>  ETEXI
>>>>  
>>>>      {
>>>> +        .name       = "dump",
>>>> +        .args_type  = "file:s",
>>>> +        .params     = "file",
>>>> +        .help       = "dump to file",
>>>> +        .user_print = monitor_user_noop,
>>>> +        .mhandler.cmd = hmp_dump,
>>>> +    },
>>>
>>> What if I want to dump only a fraction of the memory?  I think you need
>>> optional start and length parameters, to limit how much memory to be
>>> dumped, rather than forcing me to dump all memory at once.
>>>
>>
>> It is OK to support it, but I do not know why do you want it?
>>
>> The purpose of this command is dumping the memory when the guest is paniced.
>> And then we can use crash/gdb(or other application) to investigate why the 
>> guest
>> is paniced. So we should dump the whole memory.
> 
> That's one purpose, but not the only purpose.  We shouldn't be
> artificially constraining things into requiring the entire memory region
> in order to use this command.
> 
> Libvirt provides virDomainMemoryPeek which currently wraps the 'memsave'
> and 'pmemsave' monitor commands, but these commands output raw memory.
> Your command is introducing a new memory format into ELF images, and if
> 'memsave' can already do a subset of memory, it also makes sense for
> 'dump' to do a subset when creating the ELF image.  That is, if a
> management app every has a reason to access a subset of memory, then
> this reason exists whether the subset is raw or ELF formatted when
> presented to the management app.

OK. I know why you want it, and will support it. Please wait for some
days.

Thanks
Wen Congyang

> 
> Meanwhile, on the libvirt side, the virDomainMemoryPeek API to
> management apps is constrained - it sends the data inline with the
> command, rather than on a side channel.  Someday, I'd like to enhance
> libvirt to have a dump-to-stream command, and reuse the existing libvirt
> ability to stream large amounts of data on side channels, in order to
> let management apps directly and atomically query a subset of memory
> into a file with the desired formatting, rather than the current
> approach of constraining the management app to only query 64k at a time
> and to have to manually pause the guest if they need to atomically
> inspect more memory.
>