From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53955) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvSID-0004lo-Ey for qemu-devel@nongnu.org; Mon, 01 Dec 2014 09:49:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XvSI8-0006I8-K2 for qemu-devel@nongnu.org; Mon, 01 Dec 2014 09:49:37 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55673) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvSI8-0006Hf-CT for qemu-devel@nongnu.org; Mon, 01 Dec 2014 09:49:32 -0500 Date: Mon, 1 Dec 2014 14:49:24 +0000 From: "Dr. David Alan Gilbert" Message-ID: <20141201144924.GE2504@work-vm> References: <1417091366-4469-1-git-send-email-stefanha@redhat.com> <1417091366-4469-5-git-send-email-stefanha@redhat.com> <20141127162905.GG2583@work-vm> <20141201140140.GC6744@stefanha-thinkpad.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141201140140.GC6744@stefanha-thinkpad.redhat.com> Subject: Re: [Qemu-devel] [RFC 4/6] migration: move dirty bitmap sync to ram_addr.h List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Peter Maydell , rth@redhat.com, qemu-devel@nongnu.org, Juan Quintela , Paolo Bonzini * Stefan Hajnoczi (stefanha@redhat.com) wrote: > On Thu, Nov 27, 2014 at 04:29:06PM +0000, Dr. David Alan Gilbert wrote: > > * Stefan Hajnoczi (stefanha@redhat.com) wrote: > > > The dirty memory bitmap is managed by ram_addr.h and copied to > > > migration_bitmap[] periodically during live migration. > > > > > > Move the code to sync the bitmap to ram_addr.h where related code lives. > > > > Is this sync code going to need to gain a barrier (although I'm not quite > > sure which) to ensure it's picked up all changes? > > gcc makes these operations a full barrier: > https://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Atomic-Builtins.html Ah yes; actually our docs/atomics.txt is a good reference - all the operations you're using are in the sequentially consistent half of that doc. Dave > > Stefan -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK