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

[Anthony Liguori <anthony@codemonkey.ws>]

On 12/22/2009 09:54 AM, Paul Brook wrote:
>>> 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.
>>      
> IMO the best way to do this is to do it via existing VMState machinery.
> We've already matched up DeviceStates so this gets us a handy unique
> identifier for every ram block. For system memory we can add a dummy device.
> Medium term we're probably going to want this anyway.
>    

Okay, I understand and agree.

I think the way this would work is that we would have a ram_addr type 
for VMState that would be an actual ram allocation and size.  
qemu_ram_alloc() would not need to take a context.  ram live migration 
would walk the list of registered VMState entries searching for anything 
that had a ram_addr type and would add that to the ram migration.

For system ram, we need dummy devices.

I think we probably ought to integrate VMState into qdev first though.  
I think that makes everything a bit more managable.

>>> 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.
>>      
> The nice thing about the VMState approach is that the device doesn't know or
> care how the migration occurs. For bonus points it leads fairly directly to an
> object based mapping API, so we can change the implementation or migrate the
> ram to a different location without disturbing the device.
>    

Yeah, I like it.

Regards,

Anthony Liguori

> Paul
>