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

["Michael S. Tsirkin" <mst@redhat.com>]

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" <mst@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.
> >>
> >>   
> >>>> 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