[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] QEMU bumping memory bug analysis
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |