[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.