Several guest architectures give their store-release instructions RCsc
semantics, which requires the store to be ordered not only after the
memory operations that precede it, but also before any subsequent
load-acquire with RCsc semantics.  The TCG translators, however, only
emit the leading barrier before the store, so under MTTCG nothing
prevents the host CPU from executing the load-acquire that follows a
store-release before the store has left its store buffer.  On an x86
host (TSO), store-load is the only reordering the hardware may
perform, and it is exactly the ordering that is missing, so the
architecturally forbidden [0,0] outcome of the Store Buffering litmus
test is easy to observe:

    CPU 0                      CPU 1
    store-release X = 1        store-release Y = 1
    load-acquire  r0 = Y       load-acquire  r1 = X

The affected instructions are the RISC-V Zalasr store-release
instructions and the Arm STLR, STLPUR and A32/T32 STL store-release
instructions.  Neither architecture defines an RCpc store, so every
store-release is RCsc (RVWMO preserved program order Rule 7; Arm
Architecture Reference Manual DDI 0487, section B2.3.8 "Acquire and
release semantics").

Patch 1 fixes the RISC-V side and patch 2 the Arm side by emitting a
full barrier after the store as well.  Patch 3 fixes an inverted
barrier polarity found in the A32 LDA load-acquire translator while
auditing the load-acquire side.

Both fixes are verified with bare-metal Store Buffering litmus tests
under MTTCG on an x86 host:

  * RISC-V (rv64, Zalasr, 4 vCPUs): 89881 out of 100000 iterations
    produce the forbidden [0,0] result before the fix and 0 after;

  * Arm (cortex-a53, 2 vCPUs): 6 to 7 out of 100000 iterations
    produce the forbidden [0,0] result before the fix and 0 after;
    a control variant of the test that inserts a DMB ISH between the
    store and the load produces 0 out of 100000 before the fix, which
    validates the harness.

The other architectures were audited and need no change:

  * Xtensa keeps only the leading barrier for S32RI and the trailing
    one for L32AI, which exactly matches the simplified Release
    Consistency model the ISA specifies (Xtensa Instruction Set
    Architecture Reference Manual, sections 3.8.3 "Memory Access
    Ordering" and 4.3.12.3 "Inter-Processor Communication with the
    L32AI and S32RI Instructions"): the ISA orders the release store
    only after previous memory operations and the acquire load only
    before subsequent memory operations, so the Store Buffering
    litmus test is allowed there and a trailing barrier would be
    stronger than required;

  * exclusive stores and guest atomic operations are lowered to host
    atomic instructions, which are fully ordered on x86 hosts;

  * the RISC-V Ztso extension is TSO by design and explicitly allows
    store buffering.

LIU Zhiwei (3):
  target/riscv: Fix RCsc ordering of Zalasr store-release
  target/arm: Fix RCsc ordering of store-release instructions
  target/arm: Fix barrier polarity of A32 LDA load-acquire

 target/arm/tcg/translate-a64.c                   | 13 +++++++++++++
 target/arm/tcg/translate.c                       |  8 +++++++-
 target/riscv/tcg/insn_trans/trans_rvzalasr.c.inc |  8 ++++++++
 3 files changed, 28 insertions(+), 1 deletion(-)

-- 
2.43.0