[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: qdev property bug?
From: |
Alexander Graf |
Subject: |
Re: [Qemu-devel] Re: qdev property bug? |
Date: |
Mon, 14 Dec 2009 14:35:31 +0100 |
User-agent: |
Thunderbird 2.0.0.23 (X11/20090817) |
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?
>> 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.
Alex
- [Qemu-devel] Re: qdev property bug?, Michael S. Tsirkin, 2009/12/14
- Re: [Qemu-devel] Re: qdev property bug?, Alexander Graf, 2009/12/14
- Re: [Qemu-devel] Re: qdev property bug?, Michael S. Tsirkin, 2009/12/14
- Re: [Qemu-devel] Re: qdev property bug?, Anthony Liguori, 2009/12/14
- Re: [Qemu-devel] Re: qdev property bug?, Michael S. Tsirkin, 2009/12/14
- Re: [Qemu-devel] Re: qdev property bug?, Michael S. Tsirkin, 2009/12/14
- Re: [Qemu-devel] Re: qdev property bug?, Anthony Liguori, 2009/12/14
- Re: [Qemu-devel] Re: qdev property bug?, Michael S. Tsirkin, 2009/12/14
- Re: [Qemu-devel] Re: qdev property bug?, Sebastian Herbszt, 2009/12/14
- Re: [Qemu-devel] Re: qdev property bug?, Michael S. Tsirkin, 2009/12/14
- Re: [Qemu-devel] Re: qdev property bug?, Sebastian Herbszt, 2009/12/14