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

[Paul Brook <paul@codesourcery.com>]

> > 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.

> > 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.

Paul