From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36547) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V94l9-0006za-1G for qemu-devel@nongnu.org; Mon, 12 Aug 2013 22:55:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V94l1-00007H-OC for qemu-devel@nongnu.org; Mon, 12 Aug 2013 22:54:58 -0400 Received: from e28smtp03.in.ibm.com ([122.248.162.3]:53149) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V94l1-00006t-3s for qemu-devel@nongnu.org; Mon, 12 Aug 2013 22:54:51 -0400 Received: from /spool/local by e28smtp03.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 13 Aug 2013 08:17:15 +0530 Received: from d28relay05.in.ibm.com (d28relay05.in.ibm.com [9.184.220.62]) by d28dlp01.in.ibm.com (Postfix) with ESMTP id 89B40E0054 for ; Tue, 13 Aug 2013 08:25:00 +0530 (IST) Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64]) by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r7D2saqM38273174 for ; Tue, 13 Aug 2013 08:24:36 +0530 Received: from d28av02.in.ibm.com (localhost [127.0.0.1]) by d28av02.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id r7D2sc6K004019 for ; Tue, 13 Aug 2013 08:24:39 +0530 Message-ID: <52099FA3.6010207@linux.vnet.ibm.com> Date: Tue, 13 Aug 2013 10:53:23 +0800 From: Wenchao Xia MIME-Version: 1.0 References: <33FB050264B7AD4DBD6583581F2E03104B764728@nkgeml511-mbx.china.huawei.com> <20130812095903.GF29880@stefanha-thinkpad.redhat.com> <232DEBC1058FA4A5BD76D16A@Ximines.local> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] Are there plans to achieve ram live Snapshot feature? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Anthony Liguori , kvm , Marcelo Tosatti , qemu-devel , Chijianchun , Avi Kivity , Alex Bligh , fred.konrad@greensocs.com, Paul Brook 于 2013-8-12 19:33, Stefan Hajnoczi 写道: > On Mon, Aug 12, 2013 at 12:26 PM, Alex Bligh wrote: >> --On 12 August 2013 11:59:03 +0200 Stefan Hajnoczi >> wrote: >> >>> The idea that was discussed on qemu-devel@nongnu.org uses fork(2) to >>> capture the state of guest RAM and then send it back to the parent >>> process. The guest is only paused for a brief instant during fork(2) >>> and can continue to run afterwards. >> >> >> How would you capture the state of emulated hardware which might not >> be in the guest RAM? > > Exactly the same way vmsave works today. It calls the device's save > functions which serialize state to file. > > The difference between today's vmsave and the fork(2) approach is that > QEMU does not need to wait for guest RAM to be written to file before > resuming the guest. > > Stefan > I have a worry about what glib says: "On Unix, the GLib mainloop is incompatible with fork(). Any program using the mainloop must either exec() or exit() from the child without returning to the mainloop. " There is another way to do it: intercept the write in kvm.ko(or other kernel code). Since the key is intercept the memory change, we can do it in userspace in TCG mode, thus we can add the missing part in KVM mode. Another benefit of this way is: the used memory can be controlled. For example, with ioctl(), set a buffer of a fixed size which keeps the intercepted write data by kernel code, which can avoid frequently switch back to user space qemu code. when it is full always return back to userspace's qemu code, let qemu code save the data into disk. I haven't check the exactly behavior of Intel guest mode about how to handle page fault, so can't estimate the performance caused by switching of guest mode and root mode, but it should not be worse than fork(). -- Best Regards Wenchao Xia