From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42556) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rs2f5-0004A0-I2 for qemu-devel@nongnu.org; Mon, 30 Jan 2012 20:37:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rs2f3-0005dm-Oi for qemu-devel@nongnu.org; Mon, 30 Jan 2012 20:37:31 -0500 Received: from [222.73.24.84] (port=60006 helo=song.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rs2f1-0005dU-JP for qemu-devel@nongnu.org; Mon, 30 Jan 2012 20:37:29 -0500 Message-ID: <4F274668.3010402@cn.fujitsu.com> Date: Tue, 31 Jan 2012 09:39:52 +0800 From: Wen Congyang MIME-Version: 1.0 References: <4F1784EE.2040800@cn.fujitsu.com> <4F1788DD.2040301@cn.fujitsu.com> <4F18458B.50509@redhat.com> <4F262C74.6010903@cn.fujitsu.com> <4F26D119.7040308@redhat.com> In-Reply-To: <4F26D119.7040308@redhat.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Qemu-devel] [RFC][PATCH 09/15] introduce a new monitor command 'dump' to dump guest's memory List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Jan Kiszka , HATAYAMA Daisuke , Dave Anderson , qemu-devel , Luiz Capitulino 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. >