From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NKBj2-0005DG-D9 for qemu-devel@nongnu.org; Mon, 14 Dec 2009 09:16:36 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NKBix-0005Ah-B2 for qemu-devel@nongnu.org; Mon, 14 Dec 2009 09:16:35 -0500 Received: from [199.232.76.173] (port=38281 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NKBix-0005Ae-6Q for qemu-devel@nongnu.org; Mon, 14 Dec 2009 09:16:31 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54562) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NKBiw-00015s-WD for qemu-devel@nongnu.org; Mon, 14 Dec 2009 09:16:31 -0500 Date: Mon, 14 Dec 2009 16:13:41 +0200 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] Re: qdev property bug? Message-ID: <20091214141341.GB1360@redhat.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091214141143.GA1360@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: "glommer@redhat.com" , "qemu-devel@nongnu.org" , Alexander Graf , Kevin O'Connor , Gerd Hoffmann , Sebastian Herbszt On Mon, Dec 14, 2009 at 04:11:43PM +0200, Michael S. Tsirkin wrote: > On Mon, Dec 14, 2009 at 08:11:59AM -0600, Anthony Liguori wrote: > > Alexander Graf wrote: > >> Michael S. Tsirkin wrote: > >> > >>> On Mon, Dec 14, 2009 at 12:55:28PM +0100, Alexander Graf wrote: > >>> > >>>> Am 14.12.2009 um 11:59 schrieb "Michael S. Tsirkin" : > >>>> > >>>> > >>>>> On Mon, Dec 14, 2009 at 11:16:34AM +0100, Gerd Hoffmann wrote: > >>>>> > >>>>>> On 12/14/09 10:44, Michael S. Tsirkin wrote: > >>>>>> > >>>>>>> No, it did not even start booting the kernel. Just gave me > >>>>>>> blank screen. > >>>>>>> > >>>>>> [ testing ] > >>>>>> > >>>>>> Oh. That is something completely different. A bug in the rom > >>>>>> loader. > >>>>>> It fails to fit both e1000 (default nic) and virtio-net boot > >>>>>> roms into > >>>>>> the option rom area and bails out (before loading seabios). vl.c > >>>>>> doesn't check the return value and happily continues (without bios). > >>>>>> Which doesn't work out very well ... > >>>>>> > >>>>>> With two identical nics the (single) rom fits and qemu boots. > >>>>>> > >>>>>> Hmm. Of course vl.c must be fixed to check the return value. > >>>>>> > >>>>> Yes. > >>>>> > >>>>> > >>>>>> Not sure how to deal with the rom size issue. The gPXE roms > >>>>>> look quit > >>>>>> big compared to the older roms we had. > >>>>>> > >>>>> Hmm, it's a regression then ... > >>>>> > >>>> How does real hw handle this? I'm pretty sure most servers these > >>>> days use more option rom space than this. They usually have some > >>>> onboard raid bios, external storage, on-board nic, pci nic, ... > >>>> > >>> Real hardware might do several things I know about > >>> - option rom is typically small. > >>> - option rom is not loaded always (BIOS option), or not for all cards. > >>> There are might be other tricks. > >>> > >> > >> There are probably other tricks. I was booting up a machine that had > >> like 5 options roms going through their initialization that all weren't > >> exactly small. > >> > >> > >>>> So there must be some way to just have more option rom space. > >>>> > >>> What do you mean? > >>> > >> > >> Well, what's keeping us from having 5 MB of option roms? > >> > > > > For starters, option roms run in real mode when you only have 1MB of > > addressable memory :-) > > > >>>> Implementing anything else would just be a waste of time. It'd > >>>> break again when ppl do device assignment. > >>>> > >>>> Alex > >>>> > >>> We need some solution for 0.12 though IMO. > >>> This does not need to address device assignment, > >>> but it must be simple. > >>> > >> > >> Agreed. If there is a solution that gives us the chance to support an > >> arbitrary number of option roms that wouldn't take forever to implement, > >> I'd rather take that one though. > >> > > > > For 0.12, we just need to fail gracefully (meaning stop loading option > > roms when we run out of room). It's not a regression compared to 0.11. > > > > Regards, > > > > Anthony Liguori > > > Well I am pretty sure that I used virtio + e1000 with 0.11 > and apparently I can't now. > So it does look like a regression to me ... > 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. > -- > MST