On Mon, Dec 14, 2009 at 02:35:31PM +0100, 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" <m...@redhat.com>: > >> > >> > >>> 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.
This might boil down to better ROMs. E.g. maybe they request memory with PMM and then give it up after initialization? > >> 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? > > >> 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. > > Alex
