From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
Ian Jackson <Ian.Jackson@eu.citrix.com>,
Don Slutz <dslutz@verizon.com>, hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [PATCH v2 for-4.5] libxl: account for romfile memory
Date: Wed, 26 Nov 2014 09:40:40 -0500 [thread overview]
Message-ID: <20141126144040.GD8735@laptop.dumpdata.com> (raw)
In-Reply-To: <1417007040.11944.50.camel@citrix.com>
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@eu.citrix.com>
> > > > > > > > CC: Don Slutz <dslutz@verizon.com>
> > > > > > > > CC: hanyandong <hanyandong@iie.ac.cn>
> > > > > > > > CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > > > > > > CC: Ian Campbell <Ian.Campbell@citrix.com>
> > > > > > > > CC: Wei Liu <wei.liu2@citrix.com>
> > > > > > >
> > > > > > > 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.
>
next prev parent reply other threads:[~2014-11-26 14:40 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-25 12:43 [PATCH v2 for-4.5] libxl: account for romfile memory Stefano Stabellini
2014-11-25 14:24 ` Ian Campbell
2014-11-25 16:49 ` Stefano Stabellini
2014-11-25 16:56 ` Ian Campbell
2014-11-25 17:04 ` Wei Liu
2014-11-25 17:05 ` Stefano Stabellini
2014-11-26 9:32 ` Ian Campbell
2014-11-26 12:39 ` Stefano Stabellini
2014-11-26 13:04 ` Ian Campbell
2014-11-26 14:40 ` Konrad Rzeszutek Wilk [this message]
2014-11-26 20:05 ` Don Slutz
2015-01-08 13:52 ` Ian Campbell
2014-11-26 20:17 ` Don Slutz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141126144040.GD8735@laptop.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=Ian.Campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=dslutz@verizon.com \
--cc=hanyandong@iie.ac.cn \
--cc=stefano.stabellini@eu.citrix.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.