Re: [Xen-devel] [PATCH v2 for-4.5] libxl: account for romfile memory

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Wed, Nov 26, 2014 at 01:04:00PM +0000, Ian Campbell wrote:
> On Wed, 2014-11-26 at 12:39 +0000, Stefano Stabellini wrote:
> > On Wed, 26 Nov 2014, Ian Campbell wrote:
> > > On Tue, 2014-11-25 at 17:05 +0000, Stefano Stabellini wrote:
> > > > On Tue, 25 Nov 2014, Ian Campbell wrote:
> > > > > On Tue, 2014-11-25 at 16:49 +0000, Stefano Stabellini wrote:
> > > > > > On Tue, 25 Nov 2014, Ian Campbell wrote:
> > > > > > > On Tue, 2014-11-25 at 12:43 +0000, Stefano Stabellini wrote:
> > > > > > > > Account for the extra memory needed for the rom files of any 
> > > > > > > > emulated nics:
> > > > > > > > QEMU uses xc_domain_populate_physmap_exact to allocate the 
> > > > > > > > memory for
> > > > > > > > each them. Assume 256K each.
> > > > > > > 
> > > > > > > I suppose this will have to do for 4.5. Can we do something 
> > > > > > > better in
> > > > > > > the future -- like figuring out a way for guests to have
> > > > > > > "not-really-RAM" allocations like this which are made by the 
> > > > > > > toolstack
> > > > > > > and happen to be backed by RAM not count or something.
> > > > > > > 
> > > > > > > > 
> > > > > > > > This patch fixes a QEMU abort() when more than 4 emulated nics 
> > > > > > > > are
> > > > > > > > assigned to a VM.
> > > > > > > 
> > > > > > > Are you also going to fix qemu to fail gracefully if it cannot 
> > > > > > > deploy
> > > > > > > option roms? abort() seems a bit extreme.
> > > > > > > 
> > > > > > > > Signed-off-by: Stefano Stabellini 
> > > > > > > > <stefano.stabellini@xxxxxxxxxxxxx>
> > > > > > > > CC: Don Slutz <dslutz@xxxxxxxxxxx>
> > > > > > > > CC: hanyandong <hanyandong@xxxxxxxxx>
> > > > > > > > CC: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> > > > > > > > CC: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
> > > > > > > > CC: Wei Liu <wei.liu2@xxxxxxxxxx>
> > > > > > > 
> > > > > > > You missed Ian J. I've added him.
> > > > > > 
> > > > > > Actually Wei suggested a better alternative: I could call
> > > > > > xc_domain_setmaxmem directly from QEMU. That makes much more sense.
> > > > > 
> > > > > xl mem-set would do it again, but not taking qemu's extras into 
> > > > > account,
> > > > > unless you communicate the overhead somehow...
> > > > 
> > > > We could start reading the current maxmem and add to it in
> > > > libxl_set_memory_target. Or we could write the maxmem to xenstore and
> > > > read it back again.  Given that the allocations are only done by QEMU at
> > > > initialization time, I don't think we need to worry about concurrency
> > > > here.
> > > 
> > > Might work, but it's a bit scary for 4.5, I would expect there to be
> > > subtle knock on effects from this sort of thing :-/
> >  
> > Given that this is not a regression, we could wait for 4.6 to commit the
> > fix and then if it doesn't cause any unwanted side effects, we could
> > backport it?
> 
> That's not a bad plan. Release noting "you can't create more than 4
> emulated NICs" doesn't seem so bad to me.

<wipes out the sweat from his forehead>

4.6 it is then!
> 
> Ian.
> 

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