From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH Remus v2 00/10] Remus support for Migration-v2 Date: Tue, 12 May 2015 10:40:24 +0100 Message-ID: <5551CA88.9060107@citrix.com> References: <1431077610-3366-1-git-send-email-yanghy@cn.fujitsu.com> <554CFC90.1030301@citrix.com> <55504C20.8020009@cn.fujitsu.com> <55506F94.7070407@citrix.com> <55508906.1010003@cn.fujitsu.com> <55508C0D.6060904@citrix.com> <5551B5D0.9040303@cn.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5551B5D0.9040303@cn.fujitsu.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Yang Hongyang , xen-devel@lists.xen.org Cc: wei.liu2@citrix.com, ian.campbell@citrix.com, wency@cn.fujitsu.com, ian.jackson@eu.citrix.com, yunhong.jiang@intel.com, eddie.dong@intel.com, rshriram@cs.ubc.ca List-Id: xen-devel@lists.xenproject.org On 12/05/15 09:12, Yang Hongyang wrote: > >>>> That sounds like COLO wants a should_checkpoint() callback which >>>> separates the decision to make a checkpoint from the logic of >>>> implementing a checkpoint. >>> >>> We use checkpoint callback to do should_checkpoint() thing currently. >>> libxc will check the return value of checkpoint callback. >> >> But that causes a chicken & egg problem. >> >> I am planning to use a CHECKPOINT record to synchronise the transfer of >> ownership of the FD between libxc and libxl. Therefore, a CHECKPOINT >> record must be in the stream ahead of the checkpoint() callback, as >> libxl will then write/read some records in itself. > > The record name CHECKPOINT seems do not match the thing what you are > planning to do, In this case I think END-OF-CHECKPOINT which represent > the > END of libxc side checkpoint is better, when libxc side checkpoint end, > libxc should transfer the ownership of FD to libxl and let libxl to > handle the following stream. libxl side can also use END-OF-CHECKPOINT > as a sign to hand the ownership of the FD to libxc. END_OF_CHECKPOINT implies the presence of START_OF_CHECKPOINT. The current spec for CHECKPOINT is more of a sentinal value between checkpoints of data. > >> >> As a result, the checkpoint() callback itself can't be used to gate >> whether a CHECKPOINT record is written by libxc. > > I was wondering how you will do the FD transfer job? The FD needs to be readable/writable in both the libxl and libxl-save-helper processes. The CHECKPOINT record simply signals a transfer of ownership. >>>> I have a 4th alternative in mind, but would like your feedback from my >>>> comments in this email first. >>> >>> So what's the 4th alternative? >> >> I have some corrections to my patch series based on David's feedback, >> and your comments. After that, it should hopefully be far easier to >> describe. > > OK, I've addressed all comments on my series and wait for your series > to continue :-) Sent. Sorry for the delay (I also have some XenServer issues I am working on atm). ~Andrew