From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yang Hongyang Subject: Re: [PATCH Remus v2 00/10] Remus support for Migration-v2 Date: Tue, 12 May 2015 18:02:15 +0800 Message-ID: <5551CFA7.6070804@cn.fujitsu.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> <5551CA88.9060107@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5551CA88.9060107@citrix.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: Andrew Cooper , 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 05/12/2015 05:40 PM, Andrew Cooper wrote: > 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). Never mind, and thank you very much for the quick turnaround! The design looks more clear now, It really helps me a lot! > > ~Andrew > . > -- Thanks, Yang.