Re: Proper support for PCI-based option rom loading (was Re: [Qemu-devel] Re: qdev property bug?)

[Michael S. Tsirkin]

On Tue, Dec 15, 2009 at 03:45:24PM -0600, Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
>> On Tue, Dec 15, 2009 at 01:21:38PM -0600, Anthony Liguori wrote:
>>   
>>> Gerd Hoffmann wrote:
>>>     
>>>> 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?
>>>>       
>>> 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.
>>>
>>> Regards,
>>>
>>> Anthony Liguori
>>>     
>>
>>
>> I 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

Hmm. You think all this is 0.12 material?