From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Stabellini Subject: Re: QEMU bumping memory bug analysis Date: Fri, 5 Jun 2015 18:13:01 +0100 Message-ID: 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 Cc: Wei Liu , Stefano Stabellini , George Dunlap , Andrew Cooper , Ian Jackson , dslutz@verizon.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Fri, 5 Jun 2015, 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). > > > (or information used to derive max pages). > > > > Andrew, correct me if I'm wrong. > > > > 4. Add a none user configurable field in current libxl JSON structure to > > record max pages information. > > > > This is not desirable. All fields in libxl JSON should be user > > configurable. > > > > 5. Add a user configurable field in current libxl JSON structure to > > record how much more memory this domain needs. Admin is required to > > fill in that value manually. In the mean time we revert the change in > > QEMU and declare QEMU with that change buggy. > > > > No response to this so far. But in fact I consider this the most viable > > solution. > > I initially thought that this was just #4 in a silly hat and was > therefore no more acceptable than that. > > But actually I think you are suggesting that users should have to > manually request additional RAM for option roms via some new interface > and that the old thing in qemu should be deprecated and removed? > > How would a user know what value to use here? Just "a bigger one till it > works"? That's, well, not super... This should not be a user configurable field. In fact it only depends on the QEMU version in use.