Re: [PATCH] RISC-V: Add support for Ztso

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Palmer Dabbelt (palmer@rivosinc.com) wrote:
> On Thu, 29 Sep 2022 12:16:48 PDT (-0700), dgilbert@redhat.com wrote:
> > * Palmer Dabbelt (palmer@rivosinc.com) wrote:
> > > Ztso, the RISC-V extension that provides the TSO memory model, was
> > > recently frozen.  This provides support for Ztso on targets that are
> > > themselves TSO.
> > > 
> > > Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
> > > 
> > > ---
> > > 
> > 
> > > diff --git a/tcg/i386/tcg-target.h b/tcg/i386/tcg-target.h
> > > index 00fcbe297d..2a43d54fcd 100644
> > > --- a/tcg/i386/tcg-target.h
> > > +++ b/tcg/i386/tcg-target.h
> > > @@ -236,6 +236,7 @@ static inline void tb_target_set_jmp_target(uintptr_t tc_ptr, uintptr_t jmp_rx,
> > >  #include "tcg/tcg-mo.h"
> > > 
> > >  #define TCG_TARGET_DEFAULT_MO (TCG_MO_ALL & ~TCG_MO_ST_LD)
> > > +#define TCG_TARGET_SUPPORTS_MCTCG_RVTSO 1
> > 
> > Is x86's brand of memory ordering strong enough for Ztso?
> > I thought x86 had an optimisation where it was allowed to store forward
> > within the current CPU causing stores not to be quite strictly ordered.
> 
> I'm actually not sure: my understanding of the Intel memory model was that
> there's a bunch of subtle bits that don't match the various TSO
> formalizations, but the RISC-V folks are pretty adamant that Intel is
> exactly TSO.  I've gotten yelled at enough times on this one that I kind of
> just stopped caring, but that's not a good reason to have broken code so I'm
> happy to go fix it.

Many people make that mistake, please refer them to the Intel docs; the
big 'Intel 64 and IA-32 Architecture Software Developer's Manual,
Combined Volumes: 1,2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D and 4'; in the recent
version I've got (April 2022) section 8.2 covers memory ordering and
8.2.2 Memory Ordering in P6 and More Recent Processor Families says on
page 8-7 (page 3090 ish):

  In a multiple-processor system, the following ordering principles apply:
....
  Writes from an individual processor are NOT ordered with respect to the writes from other processors.
....
  Any two stores are seen in a consistent order by processors other than those performing the stores

then a bit further down, '8.2.3.5 Intra-Processor Forwarding Is Allowed'
has an example and says

    'The memory-ordering model allows concurrent stores by two processors to be seen in
    different orders by those two processors; specifically, each processor may perceive
    its own store occurring before that of the other.'

Having said that, I remember it's realyl difficult to trigger; it's ~10
years since I saw an example to trigger it, and can't remember it.

> That said, when putting together the v2 (which has TCG barriers in the
> RISC-V front-end) I couldn't even really figure out how the TCG memory model
> works in any formal capacity -- I essentially just added the fences
> necessary for Ztso on RVWMO, but that's not a good proxy for Ztso on arm64
> (and I guess not on x86, either).  Also happy to go take a crack at that
> one, but I'm not really a formal memory model person so it might not be the
> best result.

Oh I don't know TCG's model, copying in Alex.

Dave

> > 
> > Dave
> > 
> > >  #define TCG_TARGET_HAS_MEMORY_BSWAP  have_movbe
> > > 
> > > diff --git a/tcg/s390x/tcg-target.h b/tcg/s390x/tcg-target.h
> > > index 23e2063667..f423c124a0 100644
> > > --- a/tcg/s390x/tcg-target.h
> > > +++ b/tcg/s390x/tcg-target.h
> > > @@ -171,6 +171,7 @@ extern uint64_t s390_facilities[3];
> > >  #define TCG_TARGET_HAS_MEMORY_BSWAP   1
> > > 
> > >  #define TCG_TARGET_DEFAULT_MO (TCG_MO_ALL & ~TCG_MO_ST_LD)
> > > +#define TCG_TARGET_SUPPORTS_MCTCG_RVTSO 1
> > > 
> > >  static inline void tb_target_set_jmp_target(uintptr_t tc_ptr, uintptr_t jmp_rx,
> > >                                              uintptr_t jmp_rw, uintptr_t addr)
> > > --
> > > 2.34.1
> > > 
> > > 
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK