From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH v2 for-4.5] libxl: account for romfile memory Date: Wed, 26 Nov 2014 09:32:10 +0000 Message-ID: <1416994330.11944.25.camel@citrix.com> References: <1416919412-10104-1-git-send-email-stefano.stabellini@eu.citrix.com> <1416925448.32327.27.camel@citrix.com> <1416934562.11944.22.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini Cc: xen-devel@lists.xensource.com, Wei Liu , Ian Jackson , Don Slutz , hanyandong List-Id: xen-devel@lists.xenproject.org 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 > > > > > CC: Don Slutz > > > > > CC: hanyandong > > > > > CC: Konrad Rzeszutek Wilk > > > > > CC: Ian Campbell > > > > > CC: Wei Liu > > > > > > > > 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 :-/