Re: [Qemu-devel] [RFC 00/30] cmpxchg-based emulation of atomics
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
Re: [Qemu-devel] [RFC 00/30] cmpxchg-based emulation of atomics
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~
Re: [Qemu-devel] [RFC 00/30] cmpxchg-based emulation of atomics
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
