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

[Umesh Deshpande <udeshpan@redhat.com>]

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