From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yang Hongyang Subject: Re: [PATCH v2 COLOPre 04/13] tools/libxc: export xc_bitops.h Date: Mon, 15 Jun 2015 09:50:10 +0800 Message-ID: <557E2F52.3010208@cn.fujitsu.com> References: <1433734997-26570-1-git-send-email-yanghy@cn.fujitsu.com> <1433734997-26570-5-git-send-email-yanghy@cn.fujitsu.com> <1433949639.30003.100.camel@citrix.com> <5578ED78.1070208@cn.fujitsu.com> <1434012099.30003.116.camel@citrix.com> <557966C5.6040905@citrix.com> <1434020115.30003.145.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1434020115.30003.145.camel@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: Ian Campbell , Andrew Cooper Cc: wei.liu2@citrix.com, wency@cn.fujitsu.com, ian.jackson@eu.citrix.com, yunhong.jiang@intel.com, eddie.dong@intel.com, xen-devel@lists.xen.org, guijianfeng@cn.fujitsu.com, rshriram@cs.ubc.ca List-Id: xen-devel@lists.xenproject.org On 06/11/2015 06:55 PM, Ian Campbell wrote: > On Thu, 2015-06-11 at 11:45 +0100, Andrew Cooper wrote: >> On 11/06/15 09:41, Ian Campbell wrote: >>> On Thu, 2015-06-11 at 10:07 +0800, Yang Hongyang wrote: >>>> On 06/10/2015 11:20 PM, Ian Campbell wrote: >>>>> On Mon, 2015-06-08 at 11:43 +0800, Yang Hongyang wrote: >>>>>> When we are under COLO, we will send dirty page bitmap info from >>>>>> secondary to primary at every checkpoint. >>>>> ... and this is a _libxl_ operation? Is that the right layer here? >>>> For the first question, Yes, this is done in the suspend callback on >>>> restore side. We do this in libxl because currently we only added a >>>> back channel on libxl side. There're no back channel in libxc. >>>> >>>> By considering this more, if we do this in libxc part, the code will be >>>> less complex: we can drop the 4th & 9th patch of this series and also >>>> get rid of the get_dirty_pfn() callback. instead we will add a patch to >>>> add back channel in libxc. >>> That sounds better to me, but lets see what Andrew thinks. >>> >>>> For the second question, I'm not sure, what's Andrew's opinion? which >>>> is the right layer to do this operation, libxl or libxc? >> >> There are a number of bits of information which would be useful going in >> "the backchannel". >> >> Some are definitely more appropriate at the libxc level, but others are >> more appropriate at the libxl. >> >> If you recall from the hackathon, there was an Alibaba usecase where >> they wanted a positive success/fail from the receiving side that the VM >> has started up successfully before choosing between cleaning up or >> continuing the VM on the sending side. This would have to be a libxl >> level backchannel. > > FWIW this particular case is currently an xl level backchannel, but I > think your general point stands. So are you both agree that we should add a backchannel to libxc, move this operation to libxc layer, what's other tools maintainers's opinion? > >> Whatever happens, backchannel wise, it should be a sensibly >> type/length/chunk'd stream. (I think there is a spec or two floating >> around somewhere which might be a good start ;p) There should probably >> be a bit of active negotiation at the start of the backchannel to a) >> confirm you have the correct backchannel and b) the backchannel is >> actually functioning. >> >> The data on "the backchannel" is always going to be in reply to an >> action taking place in the primary channel, but there are complications >> in that the libxc bit is inherently a blocking model. In terms of >> coordination, I am leaning towards the view of it being easier and >> cleaner for each level to maintain its own backchannel communication. >> The libxc bits can expect to read some records out of the backchannel at >> each checkpoint and take appropriate actions before starting the next >> checkpoint. >> >> Thoughts? >> >> ~Andrew >> > > > . > -- Thanks, Yang.