From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NKGMt-0006Jj-21 for qemu-devel@nongnu.org; Mon, 14 Dec 2009 14:14:03 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NKGMn-00069F-7T for qemu-devel@nongnu.org; Mon, 14 Dec 2009 14:14:01 -0500 Received: from [199.232.76.173] (port=47569 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NKGMm-00068v-Vy for qemu-devel@nongnu.org; Mon, 14 Dec 2009 14:13:57 -0500 Received: from mail.gmx.net ([213.165.64.20]:44185) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1NKGMm-0007oZ-3H for qemu-devel@nongnu.org; Mon, 14 Dec 2009 14:13:56 -0500 Message-ID: <7FB8DD1225E54176BCAF5523B6AEA89B@FSCPC> From: "Sebastian Herbszt" References: <20091214093414.GA30459@redhat.com> <4B26090B.8010707@redhat.com> <20091214094406.GB32140@redhat.com> <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> In-Reply-To: <4B264AF1.6060802@codemonkey.ws> Subject: Re: [Qemu-devel] Re: qdev property bug? Date: Mon, 14 Dec 2009 20:12:48 +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: Anthony Liguori , "Michael S. Tsirkin" Cc: qemu-devel@nongnu.org, glommer@redhat.com, Kevin O'Connor , Alexander Graf , Gerd Hoffmann 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