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