Re: [Qemu-devel] [RFC 00/30] cmpxchg-based emulation of atomics

[Emilio G. Cota]

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