From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60051) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qy2Dn-0006t0-Hp for qemu-devel@nongnu.org; Mon, 29 Aug 2011 09:49:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qy2Dm-0005dD-Es for qemu-devel@nongnu.org; Mon, 29 Aug 2011 09:49:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10499) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qy2Dm-0005co-81 for qemu-devel@nongnu.org; Mon, 29 Aug 2011 09:49:50 -0400 Message-ID: <4E5B98F9.6010502@redhat.com> Date: Mon, 29 Aug 2011 09:49:45 -0400 From: Umesh Deshpande MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 3/5] Migration thread mutex List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org On 08/29/2011 05:04 AM, Stefan Hajnoczi wrote: > On Sat, Aug 27, 2011 at 7:09 PM, Umesh Deshpande wrote: >> This patch implements migrate_ram mutex, which protects the RAMBlock list >> traversal in the migration thread during the transfer of a ram from their >> addition/removal from the iothread. >> >> Note: Combination of iothread mutex and migration thread mutex works as a >> rw-lock. Both mutexes are acquired while modifying the ram_list members or RAM >> block list. >> >> Signed-off-by: Umesh Deshpande >> --- >> arch_init.c | 21 +++++++++++++++++++++ >> cpu-all.h | 3 +++ >> exec.c | 23 +++++++++++++++++++++++ >> qemu-common.h | 2 ++ >> 4 files changed, 49 insertions(+), 0 deletions(-) >> >> diff --git a/arch_init.c b/arch_init.c >> index 484b39d..9d02270 100644 >> --- a/arch_init.c >> +++ b/arch_init.c >> @@ -109,6 +109,7 @@ static int is_dup_page(uint8_t *page, uint8_t ch) >> >> static RAMBlock *last_block; >> static ram_addr_t last_offset; >> +static uint64_t last_version; > [...] >> typedef struct RAMList { >> + QemuMutex mutex; /* Protects RAM block list */ >> uint8_t *phys_dirty; >> + uint32_t version; /* To detect ram block addition/removal */ > Is there a reason why RAMList.version is uint32_t but last_version is uint64_t? No, my bad, they both should be consistent.