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

[Michael S. Tsirkin]

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


-- 
MST