Re: [Qemu-devel] [PATCH 00/10, v3] target-alpha improvements

[Jamie Lokier <jamie@shareable.org>]

Richard Henderson wrote:
> I don't see how any sort of emulation of cmpxchg/load-locked is working
> for any currently enabled nptl target.  I think how I've approached
> handling load-locked for alpha is probably the easiest way.  Slightly
> better would be if TCG had a (set of) cmpxchg opcodes, which would have
> the benefit of getting the virt->phys->host address (and segfault handling)
> more correct.  I've sort of totally ignored the faulting for now.

I guess you are thinking to save the value loaded by load-locked, and
use it as the "old" for host cmpxchg at target's store-conditional?

I'm not sure if that will have the correct behaviour for all target
architectures, where _any_ value written by another CPU during an
ll/sc sequence will prevent the sequence from proceeding, including

   CPU #0                CPU #1

   x <- load-locked(A)
   y <- load(B)
                         x+1 -> store(A)
                         y+1 -> store(B)
                         x   -> store(A)
   f(x,y) -> store-cond(A)

Unless I made a mistake, the above cannot store f(x,y+1) into A, for
any interleaving (assume strongly ordered memory or barriers), on
machines where any store by another CPU breaks the condition.  But on
machines which implement store-cond by atomic-cmpxchg using the
load-locked value, f(x,y+1) can be stored.

It'll be fine when ll/sc are only used to provide single-word atomic
calculations, but I'm not sure those are the only uses to which they
are put by any code anywhere.  E.g. if I remember rightly, there was
some discussion of a planned unusual ll/sc use on the linux-arm list,
which involved a second word, but the idea wasn't ever implemented.

-- Jamie