qemu-devel
[Top][All Lists]
Advanced

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

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


From: Anthony Liguori
Subject: Proper support for PCI-based option rom loading (was Re: [Qemu-devel] Re: qdev property bug?)
Date: Mon, 14 Dec 2009 20:37:44 -0600
User-agent: Thunderbird 2.0.0.23 (X11/20090825)

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

Attachment: 0001-Do-not-guard-qemu-shadow-ram-work-around-in-CONFIG_O.patch
Description: application/mbox

Attachment: 0001-Support-PCI-based-option-rom-loading.patch
Description: application/mbox

Attachment: 0002-Disable-CONFIG_OPTIONROMS_DEPLOYED-by-default.patch
Description: application/mbox


reply via email to

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