Re: [Xen-devel] [PATCH v12 00/26] COarse-grain LOck-stepping Virtual Machines for Non-stop Service

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Thu, Mar 24, 2016 at 04:21:36PM +0000, Ian Jackson wrote:
> Changlong Xie writes ("[PATCH v12 00/26] COarse-grain LOck-stepping Virtual 
> Machines for Non-stop Service"):
> > This patchset implemented the COLO feature for Xen.
> > For detail/install/use of COLO feature, refer to:
> > http://wiki.xen.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping
> 
> Thanks for this resend.  I have now worked my way through all the
> patches.  There are mostly only trivial problems, which will be easily
> fixed.
> 
> 
> There is IMO only one serious area of risk re COLO's acceptance for
> Xen 4.7:
> 
>   Subject: Re: [PATCH v12 14/26] primary vm suspend/resume/checkpoint code
>   Date: Thu, 24 Mar 2016 15:24:04 +0000
>   ...
>   libxl__ao_complete must not be called by some internal function in
>   this way.  Only the same layer within libxl that called AO_CREATE is
>   allowed to call libxl__ao_complete.
> 
> Fixing this will involve some code rearrangement and new code.  I am
> worried that this might not be sorted out by the Xen 4.7 freeze
> deadline.
> 

If the error handling issue only affects COLO (confined in COLO related
code, won't affect ordinary use cases), I'm fine with fixing it post
freeze.  I think this is the case because COLO code is now
self-contained.

> I recommend that you focus on fixing this patch, urgently, and post a
> new version of perhaps just that patch ("v12.1 14/26" perhaps) ASAP.
> 
> I am prepared to do some fixup myself but (i) I'm not sure I fully
> understand the new colo code well enough and (ii) I am going to be
> away, now, until Wednesday.  So relying on extensive help from me
> would be unwise.
> 
> 
> There is one other overall area of concern I have with COLO.  It's
> evident that to make use of this code, there are a number of moving
> parts which are not in xen.git and which I haven't seen.  As a result
> the API between libxl/xl and those other parts can't really be
> considered stable.
> 
> This is IMO fine at this stage of the project's lifecycle in xen.git.
> (I hope Wei, as co-maintainer of libxl, will agree.)
> 

Yes. I'm fine with COLO being experimental in 4.7 -- in fact I wouldn't
want it to be declared supported until we have a way of testing it.

> However, we really ought to be testing this code in osstest.  To do
> that we need a complete recipe for setting it up.  Ideally we would
> like code contributions for osstest.  That would also be a useful
> exercise to make sure that implementations of all the important
> components are available.
> 
> In the Xen 4.8 cycle I think we will need to look at this, with a view
> to moving COLO out of the `experimental' maturity level.
> 

That's fine.

Wei.

> Lars, do you have any input on this ?
> 
> 
> Thanks,
> Ian.

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