On Fri, Nov 10, 2017 at 1:57 PM, Mathieu Desnoyers
<mathieu.desnoyers@xxxxxxxxxxxx> wrote:
>
> That core serializing instruction is not that much about I$ vs D$
> consistency, but rather about the processor speculatively executing code
> ahead of its retirement point. Ref. Intel Architecture Software Developer's
> Manual, Volume 3: System Programming.
Oh, I know.
I'm just saying that the Intel docs wrt cross-modifying code are most
likely crap and overly defensive.
The sequence they _say_ is required can not possibly be required,
simply because people already depend on it not being required. We've
never had the serializing instruction in various other circumstances
when we switched from the old "iret" to "sysret".
I think it's kind of like the old memory ordering: Intel didn't really
document the real rules. They only started truly documenting what they
*really* did about ten years ago.
Remember when we thought you needed a locked instruction or a memory
barrier in between two reads, and our "smp_rmb()" was an actual
barrier instruction?
Yeah, that was always bogus, but it was what the (bad) intel
documentation said you had to do. Then they started fixing their docs,
and now smp_rmb() is just a compiler barrier on x86.
It's about ten years ago that we committed b6c7347fffa6 ("x86:
optimise barriers") as a response to the Intel/AMD memory ordering
whitepaper (which is now part of the standard architecture manual, but
it
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
