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
