From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33593) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvoW9-0006LA-WA for qemu-devel@nongnu.org; Tue, 23 Aug 2011 06:47:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QvoW8-0005mM-Mm for qemu-devel@nongnu.org; Tue, 23 Aug 2011 06:47:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38006) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvoW8-0005m0-Ek for qemu-devel@nongnu.org; Tue, 23 Aug 2011 06:47:36 -0400 Date: Tue, 23 Aug 2011 06:15:33 -0300 From: Marcelo Tosatti Message-ID: <20110823091533.GA5207@amt.cnet> References: <8f99d56f3a48b6255cf70425bc435d8f231f5352.1313552764.git.udeshpan@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8f99d56f3a48b6255cf70425bc435d8f231f5352.1313552764.git.udeshpan@redhat.com> Subject: Re: [Qemu-devel] [RFC PATCH v4 2/5] ramlist mutex List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Umesh Deshpande Cc: pbonzini@redhat.com, qemu-devel@nongnu.org, kvm@vger.kernel.org, quintela@redhat.com On Tue, Aug 16, 2011 at 11:56:37PM -0400, Umesh Deshpande wrote: > ramlist mutex is implemented to protect the RAMBlock list traversal in the > migration thread from their addition/removal from the iothread. > > Signed-off-by: Umesh Deshpande > --- > cpu-all.h | 2 ++ > exec.c | 19 +++++++++++++++++++ > qemu-common.h | 2 ++ > 3 files changed, 23 insertions(+), 0 deletions(-) > > diff --git a/cpu-all.h b/cpu-all.h > index 6b217a2..eab9803 100644 > --- a/cpu-all.h > +++ b/cpu-all.h > @@ -21,6 +21,7 @@ > > #include "qemu-common.h" > #include "cpu-common.h" > +#include "qemu-thread.h" > > /* some important defines: > * > @@ -932,6 +933,7 @@ typedef struct RAMBlock { > } RAMBlock; > > typedef struct RAMList { > + QemuMutex mutex; > uint8_t *phys_dirty; > QLIST_HEAD(ram, RAMBlock) blocks; > QLIST_HEAD(, RAMBlock) blocks_mru; A comment on what the mutex protects would be good.