From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NKGgE-0002GF-LU for qemu-devel@nongnu.org; Mon, 14 Dec 2009 14:34:02 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NKGg9-00024r-9Y for qemu-devel@nongnu.org; Mon, 14 Dec 2009 14:34:01 -0500 Received: from [199.232.76.173] (port=56787 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NKGg9-00024g-4L for qemu-devel@nongnu.org; Mon, 14 Dec 2009 14:33:57 -0500 Received: from mail-yw0-f171.google.com ([209.85.211.171]:57939) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NKGg8-0002rq-PW for qemu-devel@nongnu.org; Mon, 14 Dec 2009 14:33:56 -0500 Received: by ywh1 with SMTP id 1so3112462ywh.18 for ; Mon, 14 Dec 2009 11:33:55 -0800 (PST) Message-ID: <4B26931E.4000101@codemonkey.ws> Date: Mon, 14 Dec 2009 13:33:50 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: qdev property bug? 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> <7FB8DD1225E54176BCAF5523B6AEA89B@FSCPC> In-Reply-To: <7FB8DD1225E54176BCAF5523B6AEA89B@FSCPC> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sebastian Herbszt Cc: "Michael S. Tsirkin" , glommer@redhat.com, qemu-devel@nongnu.org, Alexander Graf , Kevin O'Connor , Gerd Hoffmann 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. That's a super hack :-) The fact that works is pure luck. >> 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] Well it ought to be a qdev property and it ought to be applicable to every PCI device. >> 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. I disagree. A user should not have to decide whether they want PXE boot or not when they create a VM. The less decisions a user has to make up front the easier qemu is to use. Regards, Anthony Liguori