From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NKGll-0005dN-T5 for qemu-devel@nongnu.org; Mon, 14 Dec 2009 14:39:45 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NKGlh-0005b8-UC for qemu-devel@nongnu.org; Mon, 14 Dec 2009 14:39:45 -0500 Received: from [199.232.76.173] (port=48404 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NKGlh-0005b3-Ho for qemu-devel@nongnu.org; Mon, 14 Dec 2009 14:39:41 -0500 Received: from mail.gmx.net ([213.165.64.20]:57161) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1NKGlg-0003SX-TY for qemu-devel@nongnu.org; Mon, 14 Dec 2009 14:39:41 -0500 Message-ID: <205D52FFDAF54D6BA3BB539FD0059F49@FSCPC> From: "Sebastian Herbszt" 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> <20091214192002.GB6100@redhat.com> In-Reply-To: <20091214192002.GB6100@redhat.com> Subject: Re: [Qemu-devel] Re: qdev property bug? Date: Mon, 14 Dec 2009 20:38:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: glommer@redhat.com, qemu-devel@nongnu.org, Alexander Graf , Kevin O'Connor , Gerd Hoffmann Michael S. Tsirkin wrote: > 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. I think it makes sense at least for nic and scsi. It might even be useful for vga, e.g. choose between pci/onboard and agp vga and only load one of both roms. - Sebastian