All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Andy Lutomirski' <luto@kernel.org>, Nicholas Piggin <npiggin@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>, X86 ML <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	stable <stable@vger.kernel.org>, Will Deacon <will@kernel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Paul Mackerras <paulus@samba.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: RE: [RFC please help] membarrier: Rewrite sync_core_before_usermode()
Date: Fri, 1 Jan 2021 18:33:28 +0000	[thread overview]
Message-ID: <30c0fd4917264e75a911527715f5aed3@AcuMS.aculab.com> (raw)
In-Reply-To: <CALCETrX4v1KEf6ikVtFg6juh3Z_esJ-+6PLT1A21JJeTVh2k8g@mail.gmail.com>

From: Andy Lutomirski
> Sent: 29 December 2020 00:36
...
> I mean that the mapping from the name "sync_core" to its semantics is
> x86 only.  The string "sync_core" appears in the kernel only in
> arch/x86, membarrier code, membarrier docs, and a single SGI driver
> that is x86-only.  Sure, the idea of serializing things is fairly
> generic, but exactly what operations serialize what, when things need
> serialization, etc is quite architecture specific.
> 
> Heck, on 486 you serialize the instruction stream with JMP.

Did the 486 even have a memory cache?
Never mind separate I&D caches.
Without branch prediction or an I$ a jmp is enough.
No idea how the dual 486 box we had actually behaved.

For non-SMP the x86 cpus tend to still be compatible with
the original 8086 - so are pretty much fully coherent.
ISTR the memory writes will invalidate I$ lines.

But there was some hardware compatibility that meant a load
of Pentium-75 systems were 'scavenged' from development for
a customer - we got faster P-266 boxes as replacements.

OTOH we never did work out how to do the required 'barrier'
when switching a Via C3 to and from 16-bit mode.
Sometimes it worked, other times the cpu went AWOL.
Best guess was that it sometimes executed pre-decoded
instructions for the wrong mode when returning from the
function call that flipped modes.

Then there is the P-Pro era Intel doc that says that IOR/IOW
aren't sequenced wrt memory accesses.
Fortunately all x86 processors have sequenced them.
Which is what the current docs say.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

WARNING: multiple messages have this Message-ID (diff)
From: David Laight <David.Laight@ACULAB.COM>
To: 'Andy Lutomirski' <luto@kernel.org>, Nicholas Piggin <npiggin@gmail.com>
Cc: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Catalin Marinas <catalin.marinas@arm.com>,
	X86 ML <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	stable <stable@vger.kernel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Paul Mackerras <paulus@samba.org>, Will Deacon <will@kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: RE: [RFC please help] membarrier: Rewrite sync_core_before_usermode()
Date: Fri, 1 Jan 2021 18:33:28 +0000	[thread overview]
Message-ID: <30c0fd4917264e75a911527715f5aed3@AcuMS.aculab.com> (raw)
In-Reply-To: <CALCETrX4v1KEf6ikVtFg6juh3Z_esJ-+6PLT1A21JJeTVh2k8g@mail.gmail.com>

From: Andy Lutomirski
> Sent: 29 December 2020 00:36
...
> I mean that the mapping from the name "sync_core" to its semantics is
> x86 only.  The string "sync_core" appears in the kernel only in
> arch/x86, membarrier code, membarrier docs, and a single SGI driver
> that is x86-only.  Sure, the idea of serializing things is fairly
> generic, but exactly what operations serialize what, when things need
> serialization, etc is quite architecture specific.
> 
> Heck, on 486 you serialize the instruction stream with JMP.

Did the 486 even have a memory cache?
Never mind separate I&D caches.
Without branch prediction or an I$ a jmp is enough.
No idea how the dual 486 box we had actually behaved.

For non-SMP the x86 cpus tend to still be compatible with
the original 8086 - so are pretty much fully coherent.
ISTR the memory writes will invalidate I$ lines.

But there was some hardware compatibility that meant a load
of Pentium-75 systems were 'scavenged' from development for
a customer - we got faster P-266 boxes as replacements.

OTOH we never did work out how to do the required 'barrier'
when switching a Via C3 to and from 16-bit mode.
Sometimes it worked, other times the cpu went AWOL.
Best guess was that it sometimes executed pre-decoded
instructions for the wrong mode when returning from the
function call that flipped modes.

Then there is the P-Pro era Intel doc that says that IOR/IOW
aren't sequenced wrt memory accesses.
Fortunately all x86 processors have sequenced them.
Which is what the current docs say.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

WARNING: multiple messages have this Message-ID (diff)
From: David Laight <David.Laight@ACULAB.COM>
To: 'Andy Lutomirski' <luto@kernel.org>, Nicholas Piggin <npiggin@gmail.com>
Cc: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Catalin Marinas <catalin.marinas@arm.com>,
	X86 ML <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	stable <stable@vger.kernel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Paul Mackerras <paulus@samba.org>, Will Deacon <will@kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: RE: [RFC please help] membarrier: Rewrite sync_core_before_usermode()
Date: Fri, 1 Jan 2021 18:33:28 +0000	[thread overview]
Message-ID: <30c0fd4917264e75a911527715f5aed3@AcuMS.aculab.com> (raw)
In-Reply-To: <CALCETrX4v1KEf6ikVtFg6juh3Z_esJ-+6PLT1A21JJeTVh2k8g@mail.gmail.com>

From: Andy Lutomirski
> Sent: 29 December 2020 00:36
...
> I mean that the mapping from the name "sync_core" to its semantics is
> x86 only.  The string "sync_core" appears in the kernel only in
> arch/x86, membarrier code, membarrier docs, and a single SGI driver
> that is x86-only.  Sure, the idea of serializing things is fairly
> generic, but exactly what operations serialize what, when things need
> serialization, etc is quite architecture specific.
> 
> Heck, on 486 you serialize the instruction stream with JMP.

Did the 486 even have a memory cache?
Never mind separate I&D caches.
Without branch prediction or an I$ a jmp is enough.
No idea how the dual 486 box we had actually behaved.

For non-SMP the x86 cpus tend to still be compatible with
the original 8086 - so are pretty much fully coherent.
ISTR the memory writes will invalidate I$ lines.

But there was some hardware compatibility that meant a load
of Pentium-75 systems were 'scavenged' from development for
a customer - we got faster P-266 boxes as replacements.

OTOH we never did work out how to do the required 'barrier'
when switching a Via C3 to and from 16-bit mode.
Sometimes it worked, other times the cpu went AWOL.
Best guess was that it sometimes executed pre-decoded
instructions for the wrong mode when returning from the
function call that flipped modes.

Then there is the P-Pro era Intel doc that says that IOR/IOW
aren't sequenced wrt memory accesses.
Fortunately all x86 processors have sequenced them.
Which is what the current docs say.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2021-01-01 18:35 UTC|newest]

Thread overview: 97+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-27 18:28 [RFC please help] membarrier: Rewrite sync_core_before_usermode() Andy Lutomirski
2020-12-27 18:28 ` Andy Lutomirski
2020-12-27 18:28 ` Andy Lutomirski
2020-12-27 20:18 ` Mathieu Desnoyers
2020-12-27 20:18   ` Mathieu Desnoyers
2020-12-27 21:36   ` Andy Lutomirski
2020-12-27 21:36     ` Andy Lutomirski
2020-12-27 21:36     ` Andy Lutomirski
2020-12-28 10:25     ` Russell King - ARM Linux admin
2020-12-28 10:25       ` Russell King - ARM Linux admin
2020-12-28 10:25       ` Russell King - ARM Linux admin
2020-12-28 17:14       ` Andy Lutomirski
2020-12-28 17:14         ` Andy Lutomirski
2020-12-28 17:14         ` Andy Lutomirski
2020-12-28 17:23         ` Russell King - ARM Linux admin
2020-12-28 17:23           ` Russell King - ARM Linux admin
2020-12-28 17:23           ` Russell King - ARM Linux admin
2020-12-28 18:10           ` Andy Lutomirski
2020-12-28 18:10             ` Andy Lutomirski
2020-12-28 18:10             ` Andy Lutomirski
2020-12-28 18:29         ` Jann Horn
2020-12-28 18:29           ` Jann Horn
2020-12-28 18:29           ` Jann Horn
2020-12-28 18:50           ` Andy Lutomirski
2020-12-28 18:50             ` Andy Lutomirski
2020-12-28 18:50             ` Andy Lutomirski
2020-12-28 19:08           ` Russell King - ARM Linux admin
2020-12-28 19:08             ` Russell King - ARM Linux admin
2020-12-28 19:08             ` Russell King - ARM Linux admin
2020-12-28 19:44             ` Andy Lutomirski
2020-12-28 19:44               ` Andy Lutomirski
2020-12-28 19:44               ` Andy Lutomirski
2020-12-28 20:24               ` Russell King - ARM Linux admin
2020-12-28 20:24                 ` Russell King - ARM Linux admin
2020-12-28 20:24                 ` Russell King - ARM Linux admin
2020-12-28 20:40                 ` Mathieu Desnoyers
2020-12-28 20:40                   ` Mathieu Desnoyers
2020-12-28 20:32               ` Mathieu Desnoyers
2020-12-28 20:32                 ` Mathieu Desnoyers
2020-12-28 21:06                 ` Andy Lutomirski
2020-12-28 21:06                   ` Andy Lutomirski
2020-12-28 21:06                   ` Andy Lutomirski
2020-12-28 21:26                   ` Mathieu Desnoyers
2020-12-28 21:26                     ` Mathieu Desnoyers
2020-12-29  0:36                   ` Nicholas Piggin
2020-12-29  0:36                     ` Nicholas Piggin
2020-12-29  0:36                     ` Nicholas Piggin
2020-12-29  0:56                     ` Andy Lutomirski
2020-12-29  0:56                       ` Andy Lutomirski
2020-12-29  0:56                       ` Andy Lutomirski
2020-12-29  3:09                       ` Nicholas Piggin
2020-12-29  3:09                         ` Nicholas Piggin
2020-12-29  3:09                         ` Nicholas Piggin
2020-12-29 10:44                         ` Russell King - ARM Linux admin
2020-12-29 10:44                           ` Russell King - ARM Linux admin
2020-12-29 10:44                           ` Russell King - ARM Linux admin
2020-12-30  2:33                           ` Nicholas Piggin
2020-12-30  2:33                             ` Nicholas Piggin
2020-12-30  2:33                             ` Nicholas Piggin
2020-12-30 10:00                             ` Russell King - ARM Linux admin
2020-12-30 10:00                               ` Russell King - ARM Linux admin
2020-12-30 10:00                               ` Russell King - ARM Linux admin
2020-12-30 10:58                               ` Russell King - ARM Linux admin
2020-12-30 10:58                                 ` Russell King - ARM Linux admin
2020-12-30 10:58                                 ` Russell King - ARM Linux admin
2020-12-30 11:57                                 ` Nicholas Piggin
2020-12-30 11:57                                   ` Nicholas Piggin
2020-12-30 11:57                                   ` Nicholas Piggin
2020-12-28 21:09     ` Mathieu Desnoyers
2020-12-28 21:09       ` Mathieu Desnoyers
2020-12-29  0:30       ` Andy Lutomirski
2020-12-29  0:30         ` Andy Lutomirski
2020-12-29  0:30         ` Andy Lutomirski
2020-12-29  0:11 ` Nicholas Piggin
2020-12-29  0:11   ` Nicholas Piggin
2020-12-29  0:11   ` Nicholas Piggin
2020-12-29  0:36   ` Andy Lutomirski
2020-12-29  0:36     ` Andy Lutomirski
2020-12-29  0:36     ` Andy Lutomirski
2020-12-29  3:31     ` Nicholas Piggin
2020-12-29  3:31       ` Nicholas Piggin
2020-12-29  3:31       ` Nicholas Piggin
2021-01-01 18:33     ` David Laight [this message]
2021-01-01 18:33       ` David Laight
2021-01-01 18:33       ` David Laight
2021-01-05 13:26     ` Will Deacon
2021-01-05 13:26       ` Will Deacon
2021-01-05 13:26       ` Will Deacon
2021-01-05 16:20       ` Andy Lutomirski
2021-01-05 16:20         ` Andy Lutomirski
2021-01-05 16:20         ` Andy Lutomirski
2021-01-05 16:37         ` Peter Zijlstra
2021-01-05 16:37           ` Peter Zijlstra
2021-01-05 16:37           ` Peter Zijlstra
2021-01-05 22:41         ` Will Deacon
2021-01-05 22:41           ` Will Deacon
2021-01-05 22:41           ` Will Deacon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=30c0fd4917264e75a911527715f5aed3@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=luto@kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=npiggin@gmail.com \
    --cc=paulus@samba.org \
    --cc=stable@vger.kernel.org \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.