[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC 00/30] cmpxchg-based emulation of atomics
From: |
Emilio G. Cota |
Subject: |
Re: [Qemu-devel] [RFC 00/30] cmpxchg-based emulation of atomics |
Date: |
Tue, 28 Jun 2016 15:52:31 -0400 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
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
- [Qemu-devel] [RFC 26/30] target-arm: add cmpxchg helpers for aarch64, (continued)
- [Qemu-devel] [RFC 26/30] target-arm: add cmpxchg helpers for aarch64, Emilio G. Cota, 2016/06/27
- [Qemu-devel] [RFC 17/30] target-i386: emulate LOCK'ed BTX ops using atomic helpers, Emilio G. Cota, 2016/06/27
- [Qemu-devel] [RFC 24/30] target-arm: emulate SWP with atomic_xchg helper, Emilio G. Cota, 2016/06/27
- [Qemu-devel] [RFC 30/30] target-arm: remove EXCP_STREX + cpu_exclusive_{test, info}, Emilio G. Cota, 2016/06/27
- [Qemu-devel] [RFC 18/30] target-i386: emulate XCHG using atomic helper, Emilio G. Cota, 2016/06/27
- [Qemu-devel] [RFC 28/30] linux-user: remove handling of ARM's EXCP_STREX, Emilio G. Cota, 2016/06/27
- [Qemu-devel] [RFC 21/30] target-arm: add cmpxchg helpers, Emilio G. Cota, 2016/06/27
- [Qemu-devel] [RFC 19/30] tests: add atomic_add-bench, Emilio G. Cota, 2016/06/27
- Re: [Qemu-devel] [RFC 00/30] cmpxchg-based emulation of atomics, Lluís Vilanova, 2016/06/28