> Sure, now define "total". Which accesses does that affect and which ones does it not? Is device memory included? PCIe memory? Are there ordering guarantees between mappings with different permissions?

At a basic level TSO is a model for how cores interact and devices are weird, so I'd say those get to be unspecified.

And ideally you want a line saying if the instruction cache needs to be flushed for self-modifying code since that's kind of a violation if not specified but it's a forgivable one.

> Then, define "store ordering".

Sure, though I'm not promising my wording is perfect: In TSO, when stores complete they become visible to all other cores and all cores agree on the exact same list of completed stores.

> Does it affect loads in any way? Or simply just stores?

Depends on what you mean by "affects". Loads in one core might not see stores from another core that have not yet reached the global/total list.

just speaking honestly i would not consider I$ snooping as part of the definition of TSO. it is part of the x86 memory model yes but “TSO” does not define the full story here

> when stores complete they become visible to all other cores and all cores agree on the exact same list of completed stores.

Not that they agree on what completed but on the order they completed in. That is the "o" in TSO. You inadvertently proved my point.

.

> so I'd say those get to be unspecified.

* CRASH *

You left something unspecified that mattered. Ordering of accesses to mappings with differing permissions matters, and whether they are seen in-program-order or not by other cores will break x86 emulators (main use cases for TSO).

.

That's the point here :) This is the usual "i am sure we can all agree what X means" argument - it does not work when it comes to precise things like memory models.