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

[Anthony Liguori <anthony@codemonkey.ws>]

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