From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NK8gn-0001o7-Ms for qemu-devel@nongnu.org; Mon, 14 Dec 2009 06:02:05 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NK8gi-0001m5-6a for qemu-devel@nongnu.org; Mon, 14 Dec 2009 06:02:04 -0500 Received: from [199.232.76.173] (port=41950 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NK8gh-0001m2-TF for qemu-devel@nongnu.org; Mon, 14 Dec 2009 06:01:59 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59835) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NK8gh-0000eX-I2 for qemu-devel@nongnu.org; Mon, 14 Dec 2009 06:01:59 -0500 Date: Mon, 14 Dec 2009 12:59:12 +0200 From: "Michael S. Tsirkin" Message-ID: <20091214105912.GA32355@redhat.com> References: <20091213200259.GB25615@redhat.com> <4B260683.8000506@redhat.com> <20091214093414.GA30459@redhat.com> <4B26090B.8010707@redhat.com> <20091214094406.GB32140@redhat.com> <4B261082.4030806@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B261082.4030806@redhat.com> Subject: [Qemu-devel] Re: qdev property bug? List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann , Anthony Liguori Cc: glommer@redhat.com, qemu-devel@nongnu.org, Sebastian Herbszt On Mon, Dec 14, 2009 at 11:16:34AM +0100, Gerd Hoffmann wrote: > On 12/14/09 10:44, Michael S. Tsirkin wrote: >> No, it did not even start booting the kernel. Just gave me blank screen. > > [ testing ] > > Oh. That is something completely different. A bug in the rom loader. > It fails to fit both e1000 (default nic) and virtio-net boot roms into > the option rom area and bails out (before loading seabios). vl.c > doesn't check the return value and happily continues (without bios). > Which doesn't work out very well ... > > With two identical nics the (single) rom fits and qemu boots. > > Hmm. Of course vl.c must be fixed to check the return value. Yes. > Not sure how to deal with the rom size issue. The gPXE roms look quit > big compared to the older roms we had. Hmm, it's a regression then ... > Do they have tons of features > compiled in? Can we make them smaller by disabling some? Or maybe have > *one* rom which supports *all* qemu nics? It would be larger of course, > but assuming a big share of the option rom is non-hardware specific code > which wouldn't be duplicated in memory then with two different cards it > might work out nevertheless? Haven't looked at the code at all yet. I would expect common code with all the features to be part of PXE code in BIOS, not part of option rom. Isn't this how it is structured? > Or add a nic property to disable rom > loading? Yes, and I think it should be off by default. > cheers, > Gerd Cc qemu and other people who participated in a similar discussion in the past. -- MST