Re: [Qemu-devel] [RFC 02/30] tcg: add tcg_cmpxchg_lock

[Emilio G. Cota]

On Mon, Jun 27, 2016 at 13:07:42 -0700, Richard Henderson wrote:
> On 06/27/2016 12:01 PM, Emilio G. Cota wrote:
> >This set of locks will allow us to correctly emulate cmpxchg16
> >in a parallel TCG. The key observation is that no architecture
> >supports 16-byte regular atomic load/stores; only "locked" accesses
> >(e.g. via cmpxchg16b on x86) are allowed, and therefore we can emulate
> >them by using locks.
> >
> >We use a small array of locks so that we can have some scalability.
> >Further improvements are possible (e.g. using a radix tree); but
> >we should have a workload to benchmark in order to justify the
> >additional complexity.
> >
> >Signed-off-by: Emilio G. Cota <address@hidden>
> >---
> > cpu-exec.c        |  1 +
> > linux-user/main.c |  1 +
> > tcg/tcg.h         |  5 +++++
> > translate-all.c   | 39 +++++++++++++++++++++++++++++++++++++++
> > 4 files changed, 46 insertions(+)
> 
> As formulated, this doesn't work.
> 
> In order to support cmpxchg16 without a native one, you have to use locks on
> *all* operations, lest a 4-byte atomic operation and a 16-byte operation be
> simultaneous in the same address range.

Ouch, of course you're right.
I had in mind a use case where cmpxchg16 races with other cmpxchg16's only,
which doesn't always have to be the case.

> Thankfully, the most common hosts (x86_64, aarch64, power7, s390x) do have a
> 16-byte cmpxchg, so this shouldn't really matter much in practice.
> 
> It would be nice to continue to support the other hosts (arm32, mips, ppc32,
> sparc, i686) without locks when the guest doesn't require wider atomics than
> the host suports.

ABA problem notwithstanding, as long as the guest workload doesn't require
atomics wider than that of the host, using cmpxchg as in this RFC can work.

Supporting 64-bit hosts on 32-bit guests has the problem of non-atomicity
of 64-bit accesses, however.

                E.