From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49824) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bHz3u-0001Bl-I6 for qemu-devel@nongnu.org; Tue, 28 Jun 2016 15:52:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bHz3p-0000DK-L2 for qemu-devel@nongnu.org; Tue, 28 Jun 2016 15:52:46 -0400 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:44511) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bHz3n-0000Bq-8N for qemu-devel@nongnu.org; Tue, 28 Jun 2016 15:52:41 -0400 Date: Tue, 28 Jun 2016 15:52:31 -0400 From: "Emilio G. Cota" Message-ID: <20160628195231.GA4349@flamenco> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <45b566d6-bb99-8f6c-c9de-65759544c66d@twiddle.net> <874m8dem6v.fsf@fimbulvetr.bsc.es> Subject: Re: [Qemu-devel] [RFC 00/30] cmpxchg-based emulation of atomics List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?iso-8859-1?Q?Llu=EDs?= Vilanova , Richard Henderson Cc: QEMU Developers , MTTCG Devel , Alex =?iso-8859-1?Q?Benn=E9e?= , Paolo Bonzini , Sergey Fedorov , Alvise Rigo , Peter Maydell On Tue, Jun 28, 2016 at 08:48:28 -0700, Richard Henderson wrote: > 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. Yes, exactly. Anything non-cacheable, really. > >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). But these messages wouldn't be generated as a result of calling cmpxchg on the memory-mapped I/O address, right? > 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. I'm assuming virtually all device drivers serialize accesses so that "read-modify-write" cycles can be implemented as a read+write on the bus. I have written quite a few drivers and it never occurred to me to write cmpxchg or equivalent on an I/O address. That said, for a non-RFC submission of this patchset, what should we do? Just abort() for now, or do a non-atomic cycle? Stop-the-world isn't available yet, and I wouldn't want to wait for it--this is not a huge deal-breaker for most code out there, I think. Thanks, Emilio