Re: [Xen-devel] [PATCH v2 COLOPre 04/13] tools/libxc: export xc_bitops.h

[Yang Hongyang <yanghy@xxxxxxxxxxxxxx>]

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.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel