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. > So there must be some way to just have more option rom space. What do you mean? > 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. -- MST