From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:54209)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <rth7680@gmail.com>) id 1bHvFb-0005yD-Fi
	for qemu-devel@nongnu.org; Tue, 28 Jun 2016 11:48:36 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <rth7680@gmail.com>) id 1bHvFX-00046V-TB
	for qemu-devel@nongnu.org; Tue, 28 Jun 2016 11:48:34 -0400
Received: from mail-qk0-x22a.google.com ([2607:f8b0:400d:c09::22a]:33988)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <rth7680@gmail.com>) id 1bHvFX-00046M-P4
	for qemu-devel@nongnu.org; Tue, 28 Jun 2016 11:48:31 -0400
Received: by mail-qk0-x22a.google.com with SMTP id t127so36820548qkf.1
	for <qemu-devel@nongnu.org>; Tue, 28 Jun 2016 08:48:31 -0700 (PDT)
Sender: Richard Henderson <rth7680@gmail.com>
References: <1467054136-10430-1-git-send-email-cota@braap.org>
	<874m8dem6v.fsf@fimbulvetr.bsc.es>
From: Richard Henderson <rth@twiddle.net>
Message-ID: <45b566d6-bb99-8f6c-c9de-65759544c66d@twiddle.net>
Date: Tue, 28 Jun 2016 08:48:28 -0700
MIME-Version: 1.0
In-Reply-To: <874m8dem6v.fsf@fimbulvetr.bsc.es>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
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>, QEMU Developers <qemu-devel@nongnu.org>, MTTCG Devel <mttcg@greensocs.com>, =?UTF-8?Q?Alex_Benn=c3=a9e?= <alex.bennee@linaro.org>, Paolo Bonzini <pbonzini@redhat.com>, Sergey Fedorov <serge.fdrv@gmail.com>, Alvise Rigo <a.rigo@virtualopensystems.com>, Peter Maydell <peter.maydell@linaro.org>

On 06/28/2016 01:45 AM, Lluís Vilanova wrote:
> 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).

Indeed.  Thankfully, that's rare.  Many cpus explicitly say that the atomic ops 
can't be used on non-cachable memory, since they use the cache coherency 
protocol to implement the atomicity.

That said, I can imagine that this probably works on x86, and supporting this 
is going to require a stop-the-world kind of emulation.


r~