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

[Don Slutz <dslutz@xxxxxxxxxxx>]

On 11/26/14 09:40, Konrad Rzeszutek Wilk wrote:
> 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.
The Release note needs to include that e1000 & rtl8139 have this 
restriction.
vmxnet3 does not (and cannot be used for PXE boot).

   -Don Slutz

> <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