From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59571) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RrutE-0003sC-16 for qemu-devel@nongnu.org; Mon, 30 Jan 2012 12:19:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rrut8-0003Uf-2m for qemu-devel@nongnu.org; Mon, 30 Jan 2012 12:19:35 -0500 Received: from mx1.redhat.com ([209.132.183.28]:33251) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rrut7-0003UM-Lj for qemu-devel@nongnu.org; Mon, 30 Jan 2012 12:19:29 -0500 Message-ID: <4F26D119.7040308@redhat.com> Date: Mon, 30 Jan 2012 10:19:21 -0700 From: Eric Blake MIME-Version: 1.0 References: <4F1784EE.2040800@cn.fujitsu.com> <4F1788DD.2040301@cn.fujitsu.com> <4F18458B.50509@redhat.com> <4F262C74.6010903@cn.fujitsu.com> In-Reply-To: <4F262C74.6010903@cn.fujitsu.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig1B04C60CA0CD3DAA6D6791C4" 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: Wen Congyang Cc: Jan Kiszka , HATAYAMA Daisuke , Dave Anderson , qemu-devel , Luiz Capitulino This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1B04C60CA0CD3DAA6D6791C4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 migrat= ion finished successfully. >>> ETEXI >>> =20 >>> { >>> + .name =3D "dump", >>> + .args_type =3D "file:s", >>> + .params =3D "file", >>> + .help =3D "dump to file", >>> + .user_print =3D monitor_user_noop, >>> + .mhandler.cmd =3D hmp_dump, >>> + }, >> >> What if I want to dump only a fraction of the memory? I think you nee= d >> optional start and length parameters, to limit how much memory to be >> dumped, rather than forcing me to dump all memory at once. >> >=20 > It is OK to support it, but I do not know why do you want it? >=20 > The purpose of this command is dumping the memory when the guest is pan= iced. > 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. 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. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig1B04C60CA0CD3DAA6D6791C4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJPJtEZAAoJEKeha0olJ0NqxvsH/jcZRGCBP115rFq2pZFhcqY5 Weh0VifWZbU+By6Ff1b9G9rkbLI+K/Nek6SZS55nswQptuaxH6W3+lMLhQAxM//h H0ak0/owHCms1n3M/JRVReCnar+giFAcyn8lnsTZ1/ceMLlsn2y9SxZBWcHiIGTE Dpb4dVRxtgd99puQXPSsupZbtXimyhcdAJp3k1pvsxi7bcvG7dVjh6O8viy5bv30 YXN02SUL2YrbLQs4paeayw4UrbV5m4Aos0ewuyr+FPTfOUTeEBETQbbiz8ht37Fl 7R6fNEiCYiAdvsoOKsNdc+eDsi4y2I4rJqgCEdiH0Ifw8hjg+1gQlqzjYd4s0PE= =3wCh -----END PGP SIGNATURE----- --------------enig1B04C60CA0CD3DAA6D6791C4--