From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35210) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RrjwH-0007xR-Jj for qemu-devel@nongnu.org; Mon, 30 Jan 2012 00:38:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RrjwG-000159-AW for qemu-devel@nongnu.org; Mon, 30 Jan 2012 00:38:01 -0500 Received: from [222.73.24.84] (port=50393 helo=song.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RrjwF-000150-Pm for qemu-devel@nongnu.org; Mon, 30 Jan 2012 00:38:00 -0500 Message-ID: <4F262D44.9040109@cn.fujitsu.com> Date: Mon, 30 Jan 2012 13:40:20 +0800 From: Wen Congyang MIME-Version: 1.0 References: <4F1784EE.2040800@cn.fujitsu.com> <4F17907E.4070302@cn.fujitsu.com> <4F184607.10509@redhat.com> In-Reply-To: <4F184607.10509@redhat.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 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: Eric Blake Cc: Jan Kiszka , qemu-devel , Luiz Capitulino , HATAYAMA Daisuke , Dave Anderson , Jun Koi At 01/20/2012 12:34 AM, Eric Blake Wrote: > 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 have >>>> 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. The 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? >> >> I pause the guest when the dump happens. >> >>> >>> would be wonderful if you can do the latter, since dumping a guest >>> memory can take a lot of time. >> >> Yes, it may tak a lot of time. But we dump a guest memory when the guest >> 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 design. > I do not understand this section. Do you say the reason of allowing the guest to run unpaused? Or do you say the way to do it? Thanks Wen Congyang