From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:39316)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1buacY-0006KH-U8
	for qemu-devel@nongnu.org; Thu, 13 Oct 2016 03:40:09 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1buacS-0006lt-Qj
	for qemu-devel@nongnu.org; Thu, 13 Oct 2016 03:40:06 -0400
Received: from mx6-phx2.redhat.com ([209.132.183.39]:42364)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1buacS-0006l5-Gs
	for qemu-devel@nongnu.org; Thu, 13 Oct 2016 03:40:00 -0400
Date: Thu, 13 Oct 2016 03:39:55 -0400 (EDT)
From: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <457275072.2788355.1476344395576.JavaMail.zimbra@redhat.com>
In-Reply-To: <20161012224510.GA3308@flamenco>
References: <1476107947-31430-1-git-send-email-pbonzini@redhat.com>
	<20161012224510.GA3308@flamenco>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 0/5] More thread sanitizer fixes and
 atomic.h improvements
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel/>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "Emilio G. Cota" <cota@braap.org>
Cc: qemu-devel@nongnu.org, alex bennee <alex.bennee@linaro.org>

> On Mon, Oct 10, 2016 at 15:59:02 +0200, Paolo Bonzini wrote:
> > See each patch.  My attempt at fixing whatever I did when I obviously
> > didn't know enough^W about the C11 memory model, and at setting a
> > better example for future generations...
> 
> Just for context. Building on this patchset, is it now time to
> phase out smp_(rw)mb in favour or C11's acq/rel, as you laid
> out in your KVM Forum talk [*]?

Yes, this would be the start of it.  However I'm a bit undecided
because ARMv8 doesn't have acq/rel memory barriers, and its STLR
opcode is stronger than a store release.

> What is the plan with smp_mb_(sg)et? It's not clear to me from
> the slides, but given patch 5 I don't see a reason to keep them.

No plan for now.  It makes sense to phase out at least atomic_mb_read.
atomic_mb_set is more efficient on x86 than store+mfence, so there's
that too.

Paolo