Re: [Qemu-devel] [PATCH v2] target-sh4: add atomic tas

[Paolo Bonzini <pbonzini@redhat.com>]

On 03/11/2016 17:51, Richard Henderson wrote:
>>> Well, tas_test "runs without error with this change", I suppose it fails
>>> before?  In other words, is this patch enough to run multithreaded sh4
>>> programs with qemu-user?
>>
>> It should,:the problem was reported by Adrian (cc:) while compiling ghc
>> in qemu-sh4, but I have just tested the functionality with the softmmu
>> version, not the atomicity.
>>
>> Adrian, could you test this patch?
> 
> It's a start, but sh4 has an interesting scheme to implement atomic
> sequences via special values in the stack pointer.  E.g. xchg is
> 
>     mova    1f, r0
>     mov    sp, r1
>     mov    #(0f-1f), sp
> 0:    mov.l    mem, out
>     mov.l    in, mem
> 1:    mov    r1, sp
> 
> which is only atomic if you've got a UP kernel and have code in your
> interrupt entry point that recognizes the small negative value in SP to
> reset the PC as necessary.

UP kernel = no sane way to implement this in user-mode qemu?  Doing
pattern matching on negative sp moves and the instructions in between is
probably not sane, even though GCC always has:

- mov/mov for exchange
- mov/cmpeq/bf/mov for compare-and-swap
- mov/mov/op/mov for fetch-and-foo
- mov/mov/and/not/mov for fetch-and-nand
- mov/op/mov for foo-and-fetch
- mov/and/not/mov for nand-and-fetch

Another possibility is to treat the load as a LL and the store as a SC
(implemented in turn with cmpxchg+branch if it fails).  cmpxchg spans
two basic blocks, so maybe one also needs to look at r0 and sp in
cpu_get_tb_cpu_state...

Anyhow this patch seems like a bugfix.

Paolo

> For SH4A, there are proper load-locked/store-condition insns, but prior
> to that TAS was the only truly atomic insn.