From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NKBsA-0001EW-MS for qemu-devel@nongnu.org; Mon, 14 Dec 2009 09:26:02 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NKBs6-0001DC-3T for qemu-devel@nongnu.org; Mon, 14 Dec 2009 09:26:02 -0500 Received: from [199.232.76.173] (port=49243 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NKBs6-0001D6-1P for qemu-devel@nongnu.org; Mon, 14 Dec 2009 09:25:58 -0500 Received: from mail-gx0-f222.google.com ([209.85.217.222]:35930) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NKBs6-0002eX-08 for qemu-devel@nongnu.org; Mon, 14 Dec 2009 09:25:58 -0500 Received: by gxk22 with SMTP id 22so3219958gxk.17 for ; Mon, 14 Dec 2009 06:25:57 -0800 (PST) Message-ID: <4B264AF1.6060802@codemonkey.ws> Date: Mon, 14 Dec 2009 08:25:53 -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> In-Reply-To: <20091214141341.GB1360@redhat.com> 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: "Michael S. Tsirkin" Cc: "glommer@redhat.com" , "qemu-devel@nongnu.org" , Alexander Graf , Kevin O'Connor , Gerd Hoffmann , Sebastian Herbszt 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. 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. 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. Regards, Anthony Liguori >> -- >> MST >>