From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:59329)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <vilanova@ac.upc.edu>) id 1bHoeP-0001mv-Lh
	for qemu-devel@nongnu.org; Tue, 28 Jun 2016 04:45:46 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <vilanova@ac.upc.edu>) id 1bHoeK-0008EY-HN
	for qemu-devel@nongnu.org; Tue, 28 Jun 2016 04:45:44 -0400
Received: from roura.ac.upc.edu ([147.83.33.10]:48873 helo=roura.ac.upc.es)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <vilanova@ac.upc.edu>) id 1bHoeK-0008Dy-5M
	for qemu-devel@nongnu.org; Tue, 28 Jun 2016 04:45:40 -0400
From: =?utf-8?Q?Llu=C3=ADs_Vilanova?= <vilanova@ac.upc.edu>
References: <1467054136-10430-1-git-send-email-cota@braap.org>
Date: Tue, 28 Jun 2016 10:45:28 +0200
In-Reply-To: <1467054136-10430-1-git-send-email-cota@braap.org> (Emilio
	G. Cota's message of "Mon, 27 Jun 2016 15:01:46 -0400")
Message-ID: <874m8dem6v.fsf@fimbulvetr.bsc.es>
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [Qemu-devel] [RFC 00/30] cmpxchg-based emulation of atomics
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 Developers <qemu-devel@nongnu.org>, MTTCG Devel <mttcg@greensocs.com>, Alex =?utf-8?Q?Benn=C3=A9e?= <alex.bennee@linaro.org>, Paolo Bonzini <pbonzini@redhat.com>, Richard Henderson <rth@twiddle.net>, Sergey Fedorov <serge.fdrv@gmail.com>, Alvise Rigo <a.rigo@virtualopensystems.com>, Peter Maydell <peter.maydell@linaro.org>

Emilio G Cota writes:
[...]
> - What to do when atomic ops are used on something other than RAM?
>   Should we have a "slow path" that is not atomic for these cases, or
>   it's OK to assume code is bogus? For now, I just wrote XXX.
[...]

You mean, for example, on I/O space? In these cases, it depends on the specific
device you're accessing and the interconnect used to access it.

TL;DR: In some cases, it makes sense to support atomics outside RAM.

For example, PCIe has support for expressing atomic operations in its messages
(I'm sure other interconnects do too). But in the end it depends on whether the
device supports them (I'm not sure if the device can reject atomics and produce
an error to whomever tried to do the atomic access, or if they are simply
ignored).

Cheers,
  Lluis