On 08/12/2011 02:45 AM, Paolo Bonzini wrote:
On 08/11/2011 06:20 PM, Paolo Bonzini wrote:
+ qemu_mutex_lock_ramlist();
QLIST_REMOVE(block, next);
QLIST_INSERT_HEAD(&ram_list.blocks, block, next);
+ qemu_mutex_unlock_ramlist();
Theoretically qemu_get_ram_ptr should be protected. The problem is not
just accessing the ramlist, it is accessing the data underneath it
before anyone frees it. Luckily we can set aside that problem for now,
because qemu_ram_free_from_ptr is only used by device assignment and
device assignment makes VMs unmigratable.
Hmm, rethinking about it, all the loops in exec.c should be protected
from the mutex.
Other loops in exec.c are just for reading the ram_list members, and the
migration thread doesn't modify ram_list.
Also, protecting the loops in exec.c would make those functions
un-callable from the functions that are already holding the ram_list
mutex to protect themselves against memslot removal (migration thread in
our case).
That's not too good because qemu_get_ram_ptr is a hot path for TCG.
Looks like qemu_get_ram_ptr isn't called from the source side code of
guest migration.
Perhaps you can also avoid the mutex entirely, and just disable the
above optimization for most-recently-used-block while migration is
running. It's not a complete solution, but it could be good enough
until we have RAM hot-plug/hot-unplug.
Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
