qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: qdev property bug?


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

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

> Do they have tons of features  
> compiled in?  Can we make them smaller by disabling some?  Or maybe have  
> *one* rom which supports *all* qemu nics?  It would be larger of course,  
> but assuming a big share of the option rom is non-hardware specific code  
> which wouldn't be duplicated in memory then with two different cards it  
> might work out nevertheless?

Haven't looked at the code at all yet.
I would expect common code with all the features to be part of PXE
code in BIOS, not part of option rom. Isn't this how it is structured?

>  Or add a nic property to disable rom 
> loading?

Yes, and I think it should be off by default.

> cheers,
>   Gerd

Cc qemu and other people who participated in a similar discussion
in the past.

-- 
MST




reply via email to

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