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

From: Ian Jackson <Ian.Jackson@eu.citrix.com>
To: Changlong Xie <xiecl.fnst@cn.fujitsu.com>
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Li Zhijian <lizhijian@cn.fujitsu.com>,
	Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Wen Congyang <wency@cn.fujitsu.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>,
	Dong Eddie <eddie.dong@intel.com>,
	xen devel <xen-devel@lists.xen.org>,
	Anthony Perard <anthony.perard@citrix.com>,
	Gui Jianfeng <guijianfeng@cn.fujitsu.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Yang Hongyang <hongyang.yang@easystack.cn>
Subject: Re: [PATCH v12 00/26] COarse-grain LOck-stepping Virtual Machines for Non-stop Service
Date: Thu, 24 Mar 2016 16:21:36 +0000	[thread overview]
Message-ID: <22260.5136.10322.105582@mariner.uk.xensource.com> (raw)
In-Reply-To: <1458720400-4699-1-git-send-email-xiecl.fnst@cn.fujitsu.com>

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.

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

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.

Lars, do you have any input on this ?

Thanks,
Ian.

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