From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NKBej-0003j6-4y for qemu-devel@nongnu.org; Mon, 14 Dec 2009 09:12:09 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NKBed-0003gN-Qp for qemu-devel@nongnu.org; Mon, 14 Dec 2009 09:12:08 -0500 Received: from [199.232.76.173] (port=38223 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NKBed-0003gI-NI for qemu-devel@nongnu.org; Mon, 14 Dec 2009 09:12:03 -0500 Received: from mail-gx0-f222.google.com ([209.85.217.222]:63736) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NKBec-0000YT-MT for qemu-devel@nongnu.org; Mon, 14 Dec 2009 09:12:03 -0500 Received: by gxk22 with SMTP id 22so3204658gxk.17 for ; Mon, 14 Dec 2009 06:12:02 -0800 (PST) Message-ID: <4B2647AF.1030605@codemonkey.ws> Date: Mon, 14 Dec 2009 08:11:59 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: qdev property bug? References: <20091213200259.GB25615@redhat.com> <4B260683.8000506@redhat.com> <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> In-Reply-To: <4B263F23.2090601@suse.de> 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: Alexander Graf Cc: "Michael S. Tsirkin" , "glommer@redhat.com" , "qemu-devel@nongnu.org" , Kevin O'Connor , Gerd Hoffmann , Sebastian Herbszt 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