From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: QEMU bumping memory bug analysis Date: Fri, 5 Jun 2015 18:17:29 +0100 Message-ID: <5571D9A9.7010607@citrix.com> References: <20150605164354.GK29102@zion.uk.xensource.com> <1433523491.7108.369.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1433523491.7108.369.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 , Wei Liu Cc: George Dunlap , Stefano Stabellini , Ian Jackson , dslutz@verizon.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 05/06/15 17:58, Ian Campbell wrote: > On Fri, 2015-06-05 at 17:43 +0100, Wei Liu wrote: > >> 3. Add a libxl layer that wraps necessary information, take over >> Andrew's work on libxl migration v2. Having a libxl layer that's not >> part of migration v2 is a waste of effort. >> >> There are several obstacles for libxl migration v2 at the moment. Libxl >> layer in migration v2 still has unresolved issues. It has >> inter-dependency with Remus / COLO. >> >> Most importantly it doesn't inherently solve the problem. It still >> requires the current libxl JSON blob to contain information about max >> pages > It doesn't require that, the whole point of the libxl layer is to > provide a suitable home for that information which is not the current > libxl json blob (which is user facing cfg data) or the libxc stream > (which is opaque to libxl). > > Once you have the general concept of the libxl layer, adding a new field > to it will be trivial (because it will have been designed to be > trivially extendable). Oh - I had not realised your intention of having some data blob in the libxl stream which is not the JSON configuration. Conceptually that would work, although this new information would still have to be at the head of the stream. i.e. head of the libxc blob. ~Andrew