Re: [Xen-devel] QEMU bumping memory bug analysis

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

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.

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