From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wenchao Xia Subject: Re: [Qemu-devel] [RFC]VM live snapshot proposal Date: Tue, 04 Mar 2014 19:28:10 +0800 Message-ID: <5315B8CA.8010408@gmail.com> References: <615092B2FD0E7648B6E4B43E029BCFB84D578044@SZXEMA503-MBS.china.huawei.com> <20140303123234.GC21055@stefanha-thinkpad.redhat.com> <615092B2FD0E7648B6E4B43E029BCFB84D5794D0@SZXEMA503-MBS.china.huawei.com> <20140304085456.GD25676@stefanha-thinkpad.redhat.com> <5315976B.5070608@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Stefan Hajnoczi , "Huangpeng (Peter)" , "kwolf@redhat.com" , Pavel Hrdina , Zhanghailiang , KVM devel mailing list , "qemu-devel@nongnu.org" , Wenchao Xia To: Paolo Bonzini Return-path: Received: from mail-pb0-f52.google.com ([209.85.160.52]:40498 "EHLO mail-pb0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756845AbaCDL2Y (ORCPT ); Tue, 4 Mar 2014 06:28:24 -0500 Received: by mail-pb0-f52.google.com with SMTP id rr13so5066898pbb.25 for ; Tue, 04 Mar 2014 03:28:23 -0800 (PST) In-Reply-To: <5315976B.5070608@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: =E4=BA=8E 2014/3/4 17:05, Paolo Bonzini =E5=86=99=E9=81=93: > Il 04/03/2014 09:54, Stefan Hajnoczi ha scritto: >>> Is there any other proposals to implement vm-snapshot? >> See the discussion by Paolo and Andrea about post-copy migration, wh= ich >> adds kernel memory management features for tracking userspace page >> faults. Perhaps you can use that infrastructure to trap guest writes= =2E > > That infrastructure actually traps guest reads too. But it's fine, as= =20 > they are a superset of guest writes and the image will still be=20 > consistent. > > Paolo > I heard that Kernel going to have API to let userspace catch memory=20 operation, which originally can be only caught by kernel code. I am not sure how it is now, but if=20 kernel have it, qemu can use it more gracefully than modifing migration code. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36796) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKnWT-0005pb-Qn for qemu-devel@nongnu.org; Tue, 04 Mar 2014 06:28:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WKnWL-0001F5-DL for qemu-devel@nongnu.org; Tue, 04 Mar 2014 06:28:33 -0500 Received: from mail-pb0-x231.google.com ([2607:f8b0:400e:c01::231]:40503) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKnWL-0001Ev-6N for qemu-devel@nongnu.org; Tue, 04 Mar 2014 06:28:25 -0500 Received: by mail-pb0-f49.google.com with SMTP id jt11so5068614pbb.36 for ; Tue, 04 Mar 2014 03:28:23 -0800 (PST) Message-ID: <5315B8CA.8010408@gmail.com> Date: Tue, 04 Mar 2014 19:28:10 +0800 From: Wenchao Xia MIME-Version: 1.0 References: <615092B2FD0E7648B6E4B43E029BCFB84D578044@SZXEMA503-MBS.china.huawei.com> <20140303123234.GC21055@stefanha-thinkpad.redhat.com> <615092B2FD0E7648B6E4B43E029BCFB84D5794D0@SZXEMA503-MBS.china.huawei.com> <20140304085456.GD25676@stefanha-thinkpad.redhat.com> <5315976B.5070608@redhat.com> In-Reply-To: <5315976B.5070608@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [RFC]VM live snapshot proposal List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: "kwolf@redhat.com" , Pavel Hrdina , Zhanghailiang , KVM devel mailing list , Stefan Hajnoczi , "Huangpeng (Peter)" , "qemu-devel@nongnu.org" , Wenchao Xia 于 2014/3/4 17:05, Paolo Bonzini 写道: > Il 04/03/2014 09:54, Stefan Hajnoczi ha scritto: >>> Is there any other proposals to implement vm-snapshot? >> See the discussion by Paolo and Andrea about post-copy migration, which >> adds kernel memory management features for tracking userspace page >> faults. Perhaps you can use that infrastructure to trap guest writes. > > That infrastructure actually traps guest reads too. But it's fine, as > they are a superset of guest writes and the image will still be > consistent. > > Paolo > I heard that Kernel going to have API to let userspace catch memory operation, which originally can be only caught by kernel code. I am not sure how it is now, but if kernel have it, qemu can use it more gracefully than modifing migration code.