* Palmer Dabbelt (pal...@rivosinc.com) wrote:
> On Thu, 29 Sep 2022 12:16:48 PDT (-0700), dgilb...@redhat.com wrote:
> > * Palmer Dabbelt (pal...@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 <pal...@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 / dgilb...@redhat.com / Manchester, UK
