From mboxrd@z Thu Jan  1 00:00:00 1970
From: Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 01/15] atomic: introduce atomic operations
Date: Wed, 08 Aug 2012 15:18:22 +0200
Message-ID: <5022671E.8070602@redhat.com>
References: <1344407156-25562-1-git-send-email-qemulist@gmail.com> <1344407156-25562-2-git-send-email-qemulist@gmail.com> <CAFEAcA_rnFmxzY5jGBQDg9nXBH3WmMMhd2h3=-wiY8vxQxAReg@mail.gmail.com> <CAJSP0QUiRQrKe7foKK34K812pjSq4vFbB23g8_JsAGzn43N2vA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Liu Ping Fan <qemulist@gmail.com>, qemu-devel@nongnu.org,
	kvm@vger.kernel.org, Marcelo Tosatti <mtosatti@redhat.com>,
	Blue Swirl <blauwirbel@gmail.com>, Avi Kivity <avi@redhat.com>,
	Anthony Liguori <anthony@codemonkey.ws>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	=?ISO-8859-1?Q?Andreas_F=E4rber?= <afaerber@suse.de>
To: Stefan Hajnoczi <stefanha@gmail.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:33963 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1758353Ab2HHNSe (ORCPT <rfc822;kvm@vger.kernel.org>);
	Wed, 8 Aug 2012 09:18:34 -0400
In-Reply-To: <CAJSP0QUiRQrKe7foKK34K812pjSq4vFbB23g8_JsAGzn43N2vA@mail.gmail.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

Il 08/08/2012 15:09, Stefan Hajnoczi ha scritto:
>> > NAK. We don't want random inline assembly implementations of locking
>> > primitives in QEMU, they are way too hard to keep working with all the
>> > possible host architectures we support. I spent some time a while back
>> > getting rid of the (variously busted) versions we had previously.
>> >
>> > If you absolutely must use atomic ops, use the gcc builtins. For
>> > preference, stick to higher level and less error-prone abstractions.
> We're spoilt for choice here:
> 
> 1. Atomic built-ins from gcc
> 2. glib atomics
> 
> No need to roll our own or copy the implementation from the kernel.

To some extent we need to because:

1. GCC atomics look ugly, :) do not provide rmb/wmb, and in some
versions of GCC mb is known to be (wrongly) a no-op.

2. glib atomics do not provide mb/rmb/wmb either, and
g_atomic_int_get/g_atomic_int_set are inefficient: they add barriers
everywhere, while it is clearer if you put barriers manually, and you
often do not need barriers in the get side.  glib atomics also do not
provide xchg.

I agree however that a small wrapper around GCC atomics is much better
than assembly.  Assembly can be limited to the memory barriers (where we
already have it anyway).

Paolo