|
From: | Anthony Liguori |
Subject: | Re: Proper support for PCI-based option rom loading (was Re: [Qemu-devel] Re: qdev property bug?) |
Date: | Tue, 15 Dec 2009 15:45:24 -0600 |
User-agent: | Thunderbird 2.0.0.23 (X11/20090825) |
Michael S. Tsirkin wrote:
On Tue, Dec 15, 2009 at 01:21:38PM -0600, Anthony Liguori wrote:Gerd Hoffmann wrote:Only if we care about 'info roms' working. Problem is roms is very centric now to roms at a static guest physical location. In this case, the rom lives in hardware and is mapped into physical memory based on what the guest does.On 12/15/09 03:37, Anthony Liguori wrote: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?Is this needed in the first place?Regards, Anthony LiguoriI also think it is very important to have roms sent during migration, otherwise things break if we migrate in the middle of accessing roms.
Heh, this is going to be really broken with my patches :-)We're during qemu_ram_alloc() and we currently don't have a means to associate ram with anything meaningful. This means that if you hot plug on two ends in different orders (even with fixed slots), the returned qemu_ram_alloc() pointers will be different for the same device. This means when you did the live migration of the rom contents, you'd get the wrong roms in the wrong places.
I think we need to improve how we do qemu_ram_alloc() such that we can associate some meaningful context with each allocated chunk that we can migrate with the chunk of ram.
Regards, Anthony Liguori
[Prev in Thread] | Current Thread | [Next in Thread] |