[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 COLOPre 04/13] tools/libxc: export xc_bitops.h
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |