qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: qdev property bug?


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] Re: qdev property bug?
Date: Mon, 14 Dec 2009 16:01:43 +0200
User-agent: Mutt/1.5.19 (2009-01-05)

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" <address@hidden>:
> >>
> >>     
> >>> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]