From xen-devel-bounces@lists.xen.org Mon Nov 24 12:27:41 2014 Received: (at maildrop) by bugs.xenproject.org; 24 Nov 2014 12:27:41 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1Xssk1-0007JP-S1 for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Mon, 24 Nov 2014 12:27:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xssa9-00037V-Nq; Mon, 24 Nov 2014 12:17:29 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xssa7-00037Q-Kg for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 12:17:27 +0000 Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id B6/7B-25276-6D123745; Mon, 24 Nov 2014 12:17:26 +0000 X-Env-Sender: Stefano.Stabellini@citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1416831444!14549275!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13889 invoked from network); 24 Nov 2014 12:17:26 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 24 Nov 2014 12:17:26 -0000 X-IronPort-AV: E=Sophos;i="5.07,448,1413244800"; d="scan'208";a="196034419" Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id 14.3.181.6; Mon, 24 Nov 2014 07:17:15 -0500 Received: from kaball.uk.xensource.com ([10.80.2.59]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1XssZu-0006GO-Uu; Mon, 24 Nov 2014 12:17:14 +0000 Date: Mon, 24 Nov 2014 12:17:12 +0000 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Konrad Rzeszutek Wilk In-Reply-To: <20141121190757.GA16038@laptop.dumpdata.com> Message-ID: References: <1416217990.27385.10.camel@citrix.com> <1416474814.29243.59.camel@citrix.com> <1416483731.14429.8.camel@citrix.com> <1416494946.14429.13.camel@citrix.com> <20141121173437.GA14331@laptop.dumpdata.com> <20141121190757.GA16038@laptop.dumpdata.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 X-DLP: MIA2 Cc: xen-devel@lists.xensource.com, Wei Liu , Ian Campbell , Stefano Stabellini , Ian Jackson , hanyandong Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: do not load roms for any NICs except the first to avoid wasting memory X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote: > On Fri, Nov 21, 2014 at 06:48:53PM +0000, Stefano Stabellini wrote: > > On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote: > > > On Fri, Nov 21, 2014 at 05:11:09PM +0000, Stefano Stabellini wrote: > > > > The rom is used for pxebooting. We don't need to allow pxebooting from > > > > more than one network card. Loading a romfile for every NIC wastes > > > > > > Why not? Why can't we PXE boot from each network card? > > > > I take it back: you are right, at the moment it is actually possible to > > pxe boot from the fourth nic for example. Maybe we could just load the > > first four romfiles and skip the others (four is the limit before QEMU > > fails to allocate any more memory). > > The limit is in the count of ROMs or the memory consumption? The limit is memory consumption. > What if you also do PCI passthrough? Does that figure in this calculation? In the case of PCI passthrough, roms are remapped, so they shouldn't affect memory consumption. > > TBH not all the emulated nics need a romfile but I wouldn't want to go > > down at that level of details beause they become QEMU implementation > > details. I wouldn't want to tie libxl to a certain version of QEMU in > > any way. > > > > A better way would be handling memory allocation errors in QEMU but QEMU > > doesn't do that at the moment and the change there would be certainly > > more invasive that a couple of lines in libxl. > > > > > > > > memory and as a matter of fact breaks configurations with more than 4 > > > > NICs as QEMU fails to allocate memory on behalf of the guest. > > > > > > What if you have four different type of NICs? Say 1 rlt8193, 1 e1000, one eepro, > > > and ne2k ? > > > > > > Don't you want to load the ROM for each one? > > > > The rom cannot be reused in QEMU among multiple instances of the same > > nic, so having four different types of nics or just one type doesn't > > change anything. > > > > > > > > With this fix, it is possible to assign more than 4 rtl8139 NICs to the > > > > guest. > > > > > > > > Signed-off-by: Stefano Stabellini > > > > > > > > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c > > > > index 3e191c3..f907ca9 100644 > > > > --- a/tools/libxl/libxl_dm.c > > > > +++ b/tools/libxl/libxl_dm.c > > > > @@ -674,9 +674,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc, > > > > LIBXL_NIC_TYPE_VIF_IOEMU); > > > > flexarray_append(dm_args, "-device"); > > > > flexarray_append(dm_args, > > > > - libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s", > > > > + libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s%s", > > > > nics[i].model, nics[i].devid, > > > > - nics[i].devid, smac)); > > > > + nics[i].devid, smac, > > > > + i ? ",romfile=\"\"" : "")); > > > > flexarray_append(dm_args, "-netdev"); > > > > flexarray_append(dm_args, GCSPRINTF( > > > > "type=tap,id=net%d,ifname=%s," > > > > > > > > _______________________________________________ > > > > Xen-devel mailing list > > > > Xen-devel@lists.xen.org > > > > http://lists.xen.org/xen-devel > > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel