qemu-devel
[Top][All Lists]
Advanced

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

Re: Proper support for PCI-based option rom loading (was Re: [Qemu-devel


From: Michael S. Tsirkin
Subject: Re: Proper support for PCI-based option rom loading (was Re: [Qemu-devel] Re: qdev property bug?)
Date: Tue, 15 Dec 2009 12:51:30 +0200
User-agent: Mutt/1.5.19 (2009-01-05)

On Mon, Dec 14, 2009 at 08:37:44PM -0600, Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
>> On Mon, Dec 14, 2009 at 02:44:34PM -0600, Anthony Liguori wrote:
>>   
>>> Michael S. Tsirkin wrote:
>>>     
>>>> Or, we could have a very small ROM, that loads
>>>> more actual code from card or from qemu directly
>>>> when it is run.
>>>>         
>>> It's not as simple as it sounds but it's possible, in theory at least.
>>>
>>> But I think the question really is, what problem are we trying to solve?
>>>     
>>
>> Support 256 devices on PCI bus seamlessly
>
> Okay, I think I've figured out how this is supposed to work.  With these  
> two patches to SeaBIOS and the patch to qemu, I can run:
>
> qemu -net nic,model=rtl8139 -net nic,model=virtio -net nic,model=e1000  
> -boot menu=on
>
> And all three option roms load.  I can also select which NIC I want to  
> boot from using the F12 menu.  This works by not actually loading the  
> option roms in the 1M space, but instead making them mappable through  
> the PCI devices.  With PMM and DDIM, the result is that we only have to  
> copy in 2K for each option rom which means we can support up to 48  
> unique option roms.  That should be plenty for now.
>
> These patches are very rough but I'll clean them up tomorrow.  I'm not  
> sure the best way to integrate with the rom infrastructure since we no  
> longer have a physical address to map to.  Any suggestions Gerd?
>
> Regards,
>
> Anthony Liguori

>From a quick overview, I see register memory but no unregister?

-- 
MST




reply via email to

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