Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.

[Anthony Liguori <anthony@codemonkey.ws>]

On 12/22/2009 07:04 AM, Paul Brook wrote:
>>> We should just qemu_ram_alloc() that memory regardless of whether we
>>> every map it into the guest.  Since roms can be large, we want to send
>>> their contents over during the live part of migration.  If we use
>>> qemu_ram_alloc(), we get that for free.
>>>        
>> Currently live migration uses ram_addrs, so this would work.  But
>> ram_addrs have no meaning in the guest and thus depend on qemu
>> implementation details.  IMO we should switch live migration to use
>> guest physical addresses, which would require a different migration
>> implementation for roms.  Most of it can be shared with ram, though.
>>      
> Ram allocations should be associated with a device. The VMState stuff this
> should make this fairly straightforward.
>    

Right, but for the sake of simplicity, you don't want to treat that ram 
any differently than main ram wrt live migration.  That's why I proposed 
adding a context id for each ram region.  That would allow us to use 
something like the qdev name + id as the context id for a ram chunk to 
get that association while still doing live ram migration of the memory.

> Guest address space mappings are a completely separate issue. The device
> should be migrating the mappings (directly or via a PCI BAR) as part of its
> state migration. The ram regions might not be mapped into guest address space
> at all.
>    

We don't migrate guest address space memory today.  We migrate anything 
that's qemu_ram_alloc()'d.  The big problem we have though is that we 
don't have any real association between the qemu_ram_alloc() results and 
what the context of the allocation was.  We assume the order of these 
allocations are fixed and that's entirely wrong.

For non-device qemu_ram_alloc()'s, we could either create essentially 
dummy ram devices or we could just special case it.

Regards,

Anthony Liguori

> Paul
>