On 12/20/2009 05:31 PM, Anthony Liguori wrote:
Avi Kivity 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.
I'd rather do (id, offset) instead of guest physical address. Guest
physical addresses map to ram_addrs in chunks. Each chunk usually has
some reasonable identification (below 640k, above 1mb, above 4gb,
etc.). Other type of memory like roms and vga lfb memory aren't
always part of the guest physical address space but nonetheless still
need to be migrated. This gives us one mechanism to support everything.
What about hotplugged memory? I guess we can introduce the notion of
user-visible memory slots; those exist on real hardware as well. These
slots would be different from the kvm memory slots, of course.
ids do have a nice property in that pci memory can be migrated while its
BAR changes. With gpa you'd need special handling.
--
error compiling committee.c: too many arguments to function