Re: [RFC PATCH 0/2] x86: Fix missing core serialization on migration

From: Linus Torvalds <torvalds@linux-foundation.org>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Andy Lutomirski <luto@kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-api <linux-api@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Boqun Feng <boqun.feng@gmail.com>, Andrew Hunter <ahh@google.com>,
	maged michael <maged.michael@gmail.com>,
	Avi Kivity <avi@scylladb.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Dave Watson <davejwatson@fb.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Andrea Parri <parri.andrea@gmail.com>,
	"Russell King, ARM Linux" <linux@armlinux.org.uk>,
	Greg Hackmann <ghackmann@google.com>,
	Will Deacon <will.deacon@arm.com>, David Sehr <sehr@google.com>,
	x86 <x86@kernel.org>
Subject: Re: [RFC PATCH 0/2] x86: Fix missing core serialization on migration
Date: Fri, 10 Nov 2017 14:12:59 -0800	[thread overview]
Message-ID: <CA+55aFxdzip-cnTvG_g6CrwXrLKzExngQT9cj5tg0WUqn5xTHA@mail.gmail.com> (raw)
In-Reply-To: <885227610.13045.1510351034488.JavaMail.zimbra@efficios.com>

On Fri, Nov 10, 2017 at 1:57 PM, Mathieu Desnoyers
<mathieu.desnoyers@efficios.com> 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