Re: [RFC PATCH v3 3/4] lock to protect memslots

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux