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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

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


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