[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 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. > 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 |