TSO memory model is indeed a standard option on RISC-V, that no one had implemented yet as far as I know. Software designed for the normal RISC-V memory model

TSO memory model is indeed a standard option on RISC-V, that no one had implemented yet as far as I know. Software designed for the normal RISC-V memory model will work perfectly on a TSO machine, if perhaps a bit more slowly. Programs that depend on TSO semantics may be buggy on the standard RISC-V memory model (or on ARM too). RISC-V also has a FENCE.TSO instruction that can be inserted as needed into software running on normal RISC-V. If you're going to use it a lot then you'd be better off implementing an actual TSO mode (not least because of code size). FENCE.TSO even works on (standards compliant) hardware that doesn't know about it, because unknown fences are supposed to be executed as FENCE RW,RW (the strongest fence), at some loss in efficiency. Alibaba T-Head unfortunately didn't read this part of the spec when they designed the C906 and C910 cores, which give illegal instruction trap if they encounter an unknown fence such as FENCE.TSO. OpenSBI now does trap-and-emulate if necessary, but of course at another loss of efficiency. This bug affects the Allwinner D1 and Alibaba ICE SoC. I don't know whether this errata in the C910 has been fixed in the TH1520 SoC in the Roma laptop (and other unannounced, cheaper, SBCs).