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 15:24:23 +0200
User-agent: Mutt/1.5.19 (2009-01-05)

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.

> 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




reply via email to

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