From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zhao Yan Subject: Re: [PATCH 0/5] QEMU VFIO live migration Date: Wed, 20 Feb 2019 23:21:11 -0500 Message-ID: <20190221042111.GO16456@joy-OptiPlex-7040> References: <1550566254-3545-1-git-send-email-yan.y.zhao@intel.com> <33183CC9F5247A488A2544077AF19020DB25D374@dggeml511-mbx.china.huawei.com> <20190221002444.GH16456@joy-OptiPlex-7040> <33183CC9F5247A488A2544077AF19020DB25E1F3@dggeml511-mbx.china.huawei.com> <20190221020457.GL16456@joy-OptiPlex-7040> <33183CC9F5247A488A2544077AF19020DB25E7CD@dggeml511-mbx.china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "cjia@nvidia.com" , "kvm@vger.kernel.org" , "aik@ozlabs.ru" , "Zhengxiao.zx@Alibaba-inc.com" , "shuangtai.tst@alibaba-inc.com" , "qemu-devel@nongnu.org" , "kwankhede@nvidia.com" , "eauger@redhat.com" , "yi.l.liu@intel.com" , "eskultet@redhat.com" , "ziye.yang@intel.com" , "mlevitsk@redhat.com" , "pasic@linux.ibm.com" , "felipe@nutanix.com" , "Ken.Xue@amd.com" , "kevin.tian@intel.com" , "dgilbert@redhat.com" , "alex.williamson@redhat.com" , "intel-gvt-dev@lists.freedesktop.org" Return-path: Content-Disposition: inline In-Reply-To: <33183CC9F5247A488A2544077AF19020DB25E7CD@dggeml511-mbx.china.huawei.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel2=m.gmane.org@nongnu.org Sender: "Qemu-devel" List-Id: kvm.vger.kernel.org On Thu, Feb 21, 2019 at 03:16:45AM +0000, Gonglei (Arei) wrote: > > > > > -----Original Message----- > > From: Zhao Yan [mailto:yan.y.zhao@intel.com] > > Sent: Thursday, February 21, 2019 10:05 AM > > To: Gonglei (Arei) > > Cc: alex.williamson@redhat.com; qemu-devel@nongnu.org; > > intel-gvt-dev@lists.freedesktop.org; Zhengxiao.zx@Alibaba-inc.com; > > yi.l.liu@intel.com; eskultet@redhat.com; ziye.yang@intel.com; > > cohuck@redhat.com; shuangtai.tst@alibaba-inc.com; dgilbert@redhat.com; > > zhi.a.wang@intel.com; mlevitsk@redhat.com; pasic@linux.ibm.com; > > aik@ozlabs.ru; eauger@redhat.com; felipe@nutanix.com; > > jonathan.davies@nutanix.com; changpeng.liu@intel.com; Ken.Xue@amd.com; > > kwankhede@nvidia.com; kevin.tian@intel.com; cjia@nvidia.com; > > kvm@vger.kernel.org > > Subject: Re: [PATCH 0/5] QEMU VFIO live migration > > > > > > > > > > > 5) About log sync, why not register log_global_start/stop in > > > > vfio_memory_listener? > > > > > > > > > > > > > > seems log_global_start/stop cannot be iterately called in pre-copy phase? > > > > for dirty pages in system memory, it's better to transfer dirty data > > > > iteratively to reduce down time, right? > > > > > > > > > > We just need invoking only once for start and stop logging. Why we need to > > call > > > them literately? See memory_listener of vhost. > > > > > the dirty pages in system memory produces by device is incremental. > > if it can be got iteratively, the dirty pages in stop-and-copy phase can be > > minimal. > > :) > > > I mean starting or stopping the capability of logging, not log sync. > > We register the below callbacks: > > .log_sync = vfio_log_sync, > .log_global_start = vfio_log_global_start, > .log_global_stop = vfio_log_global_stop, > .log_global_start is also a good point to notify logging state. But if notifying in .save_setup handler, we can do fine-grained control of when to notify of logging starting together with get_buffer operation. Is there any special benifit by registering to .log_global_start/stop? > Regards, > -Gonglei