From mboxrd@z Thu Jan 1 00:00:00 1970 From: Umesh Deshpande Subject: Re: [RFC PATCH v3 3/4] lock to protect memslots Date: Mon, 15 Aug 2011 02:45:12 -0400 Message-ID: <4E48C078.50109@redhat.com> References: <4E440131.6020200@redhat.com> <4E44CC1E.202@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, quintela@redhat.com, mtosatti@redhat.com To: Paolo Bonzini Return-path: Received: from mx1.redhat.com ([209.132.183.28]:23343 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752008Ab1HOGpN (ORCPT ); Mon, 15 Aug 2011 02:45:13 -0400 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p7F6jC2k004396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 15 Aug 2011 02:45:13 -0400 In-Reply-To: <4E44CC1E.202@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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