On Fri, Aug 12, 2011 at 08:45:50AM +0200, 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. That's not too good because > qemu_get_ram_ptr is a hot path for TCG. Right. > 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. Actually the previous patchset does not traverse the ramlist without qemu_mutex locked, which is safe versus the most-recently-used-block optimization. So, agreed that the new ramlist lock is not necessary for now. -- 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
