From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37780) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RnuwX-0001tv-OG for qemu-devel@nongnu.org; Thu, 19 Jan 2012 11:34:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RnuwR-0007md-8z for qemu-devel@nongnu.org; Thu, 19 Jan 2012 11:34:29 -0500 Received: from mx1.redhat.com ([209.132.183.28]:52334) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RnuwR-0007mH-1X for qemu-devel@nongnu.org; Thu, 19 Jan 2012 11:34:23 -0500 Message-ID: <4F184607.10509@redhat.com> Date: Thu, 19 Jan 2012 09:34:15 -0700 From: Eric Blake MIME-Version: 1.0 References: <4F1784EE.2040800@cn.fujitsu.com> <4F17907E.4070302@cn.fujitsu.com> In-Reply-To: <4F17907E.4070302@cn.fujitsu.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig4F185B2C6839B29F3FB933DA" Subject: Re: [Qemu-devel] [RFC][PATCH 00/15 v5] introducing a new, dedicated memory dump mechanism List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wen Congyang Cc: Jan Kiszka , qemu-devel , Luiz Capitulino , HATAYAMA Daisuke , Dave Anderson , Jun Koi This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4F185B2C6839B29F3FB933DA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 01/18/2012 08:39 PM, Wen Congyang wrote: > At 01/19/2012 11:32 AM, Jun Koi Wrote: >> On Thu, Jan 19, 2012 at 10:50 AM, Wen Congyang = wrote: >>> Hi, all >>> >>> 'virsh dump' can not work when host pci device is used by guest. We h= ave >>> discussed this issue here: >>> http://lists.nongnu.org/archive/html/qemu-devel/2011-10/msg00736.html= >>> >>> We have determined to introduce a new command dump to dump memory. Th= e core >>> file's format can be elf. >> >> do you pause the guest when the dump happen, or you can somehow let it= >> continue to run? >=20 > I pause the guest when the dump happens. >=20 >> >> would be wonderful if you can do the latter, since dumping a guest >> memory can take a lot of time. >=20 > Yes, it may tak a lot of time. But we dump a guest memory when the gues= t > panics, and there is no need to continue to run the guest. Would it be possible to have both a dump from a certain point in time and still allow the guest to run unpaused? I'm thinking something along the lines of pausing the guest, setting up control structures, then calling fork(). The parent can then unpause, and use the control structures to communicate the memory state from the child back out the monitor. Meanwhile, the guest has a copy-on-write clone of the entire memory state, so as long as the control structures guarantee that the child will not accept any monitor commands and not resume the guest, then the child process can be used to stream the memory contents as they were at the time of the dump command back over the control structure back to the parent process. I will admit, however, that following the fork(), you would be limited to async-signal-safe functions, so it may be a rather difficult task to desi= gn. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig4F185B2C6839B29F3FB933DA 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/ iQEcBAEBCAAGBQJPGEYHAAoJEKeha0olJ0Nqg3oIAKfXC65OhrN4eDXsRJqHjmtw xZGypHY4iN9BUXoNgOGJnhVAcdDrF37xanyBDsSsexalrDtUJA3cgjOI1qaz4vKc g0mvx0yGzlIQ83N2TUXasayi7gghuL1kt//w6ZwjQpmK+Weh0AaP9jt69w5QeUpn Q5BfvxTm2uAlJBvV/n+Idq7riDP2IiSeFCyS7bvwTLV4R9j4U1faRXdUO+7X6ENB msIr+OHjuQg0XWgL2iombHdjEXlqUv+mFxW1+b9FJJKh6KLYguo5TXG3cgn6Vdut JBNwjcicZgMEGP31sjYG4k37YOfjv6fo8EojSJFIONv/g0SPn0gGhc0ghEs513k= =COoN -----END PGP SIGNATURE----- --------------enig4F185B2C6839B29F3FB933DA--