From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NKGVV-00031I-0t for qemu-devel@nongnu.org; Mon, 14 Dec 2009 14:22:57 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NKGVQ-0002yW-5F for qemu-devel@nongnu.org; Mon, 14 Dec 2009 14:22:56 -0500 Received: from [199.232.76.173] (port=41513 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NKGVP-0002yI-Mz for qemu-devel@nongnu.org; Mon, 14 Dec 2009 14:22:51 -0500 Received: from mx1.redhat.com ([209.132.183.28]:30645) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NKGVP-0000jS-6H for qemu-devel@nongnu.org; Mon, 14 Dec 2009 14:22:51 -0500 Date: Mon, 14 Dec 2009 21:20:02 +0200 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] Re: qdev property bug? Message-ID: <20091214192002.GB6100@redhat.com> References: <4B261082.4030806@redhat.com> <20091214105912.GA32355@redhat.com> <1913984B-EF3F-4974-830A-DF97B8410AA6@suse.de> <20091214132423.GB973@redhat.com> <4B263F23.2090601@suse.de> <4B2647AF.1030605@codemonkey.ws> <20091214141143.GA1360@redhat.com> <20091214141341.GB1360@redhat.com> <4B264AF1.6060802@codemonkey.ws> <7FB8DD1225E54176BCAF5523B6AEA89B@FSCPC> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7FB8DD1225E54176BCAF5523B6AEA89B@FSCPC> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sebastian Herbszt Cc: glommer@redhat.com, qemu-devel@nongnu.org, Alexander Graf , Kevin O'Connor , Gerd Hoffmann On Mon, Dec 14, 2009 at 08:12:48PM +0100, Sebastian Herbszt wrote: > Anthony Liguori wrote: >> Michael S. Tsirkin wrote: >>> >>> Further, we should error out when device is added. >>> Doing this during boot is way too late, management >>> won't be able to understand such errors and >>> won't be able to recover. >>> >> >> I don't quite understand this. >> >> In 0.11, we never loaded option roms unless a user specified -boot n. >> If a user specified -boot n and used more than one nic type, I'm fairly >> certain it would error out during start up because it would run out of >> option rom space. Maybe it required three types of nics, but the point >> still remains. > > I think it used to be possible to have two different nic types and only load > one rom, e.g. -net nic,model=pcnet -net nic,model=e1000 -option-rom e1000.rom > Then use the boot menu to select the e1000 nic. > >> In 0.12, we always load the option rom for a PCI device. An easy >> solution here would be to just gracefully handle the case where we ran >> out of option rom space and (silently) stop loading additional roms. >> With respect to -boot n, it makes the behavior buggy (you cannot boot >> from the second nic) but my original point is that that is not a >> regression from 0.11. > > Even if i repeat myself [1] i suggest putting an option-rom loading flag to the -net option: > -net nic,model=e1000,rom=[on,off,e1000.bin] > >> For 0.13, we should probably allow a user to suppress option rom >> loading for a given PCI device. The limited space is a pretty good >> justification for that. > > The default behaviour should be not loading option-roms; users should request those. > > [1] http://lists.gnu.org/archive/html/qemu-devel/2009-11/msg01095.html > > - Sebastian I am not sure I agree. This is common for PXE and I think makes sense there, but I think this might not make sense for VGA rom or e.g. scsi. -- MST