From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: Xen 4.5 development update (July update) Date: Wed, 3 Sep 2014 12:27:16 +0100 Message-ID: <5406FB14.6040900@citrix.com> References: <20140902204500.D39D0DC99F@laptop.dumpdata.com> <540635D1.1070403@citrix.com> <1409738994.5020.1.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XP8io-0004ID-TO for xen-devel@lists.xenproject.org; Wed, 03 Sep 2014 11:27:31 +0000 In-Reply-To: <1409738994.5020.1.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: artem.mygaiev@globallogic.com, msw@amazon.com, ian.jackson@eu.citrix.com, Steve.VanderLeest@dornerworks.com, dongxiao.xu@intel.com, mengxu@cis.upenn.edu, chao.p.peng@linux.intel.com, zhigang.x.wang@oracle.com, parth.dixit@linaro.org, P.aul.Skentzos@dornerworks.com, wency@cn.fujitsu.com, rcojocaru@bitdefender.com, guijianfeng@cn.fujitsu.com, Vijaya.Kumar@caviumnetworks.com, stefano.stabellini@eu.citrix.com, feng.wu@intel.com, josh.whitehead@dornerworks.com, zoltan.kiss@citrix.com, avanzini.arianna@gmail.com, anthony.perard@citrix.com, xen-devel@lists.xenproject.org, serge.broslavsky@linaro.org, andrii.tseglytskyi@globallogic.com, yjhyun.yoo@samsung.com, olaf@aepfle.de, vijay.kilari@gmail.com, mcgrof@suse.com, julien.grall@linaro.org, dave.scott@citrix.com, robert.vanvossen@dornerworks.com, shantong.kang@intel.com, roy.franz@linaro.org, yang.z.zhang@intel.com, Paul.Durr List-Id: xen-devel@lists.xenproject.org On 03/09/14 11:09, Ian Campbell wrote: > On Tue, 2014-09-02 at 22:25 +0100, Andrew Cooper wrote: >>> * New Migration (v2). (good) >>> v6 posted, going on the 'good' side! >>> - Andrew Cooper & David Vrabel >> Work on the {lib,}xl side of things are making progress. >> >> Given the lack of stream versioning, *even* at the libxl level, both >> sets of changes need to go in together, so there is no chance of >> deferring the libxl work. > There is a protocol at the xl level which includes a (string) > indentifier which could be used if needed. See savefileheader_magic[] in > xl_cmdimpl.c, e.g. Wei modifies this as part of his changes to stream > the guest CFG as json instead of as an xl.cfg. > > Ian. > That is fine for xl, but not libxl which lacks any protocol version. Consumers of the libxl api other than xl currently have an opaque handle to raw libxc stream and no metadata. I have just published draft A of the libxl stream specification, which should hopefully clear up what is trying to be done along these lines. ~Andrew