Date: Thu, 11 Apr 2024 14:28:54 +0100
From: Will Deacon <will@...nel.org>
To: Hector Martin <marcan@...can.st>
Cc: Catalin Marinas <catalin.marinas@....com>,
	Marc Zyngier <maz@...nel.org>, Mark Rutland <mark.rutland@....com>,
	Zayd Qumsieh <zayd_qumsieh@...le.com>,
	Justin Lu <ih_justin@...le.com>,
	Ryan Houdek <Houdek.Ryan@...-emu.org>,
	Mark Brown <broonie@...nel.org>, Ard Biesheuvel <ardb@...nel.org>,
	Mateusz Guzik <mjguzik@...il.com>,
	Anshuman Khandual <anshuman.khandual@....com>,
	Oliver Upton <oliver.upton@...ux.dev>,
	Miguel Luis <miguel.luis@...cle.com>,
	Joey Gouly <joey.gouly@....com>,
	Christoph Paasch <cpaasch@...le.com>,
	Kees Cook <keescook@...omium.org>,
	Sami Tolvanen <samitolvanen@...gle.com>,
	Baoquan He <bhe@...hat.com>, Joel Granados <j.granados@...sung.com>,
	Dawei Li <dawei.li@...ngroup.cn>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Florent Revest <revest@...omium.org>,
	David Hildenbrand <david@...hat.com>,
	Stefan Roesch <shr@...kernel.io>, Andy Chiu <andy.chiu@...ive.com>,
	Josh Triplett <josh@...htriplett.org>,
	Oleg Nesterov <oleg@...hat.com>, Helge Deller <deller@....de>,
	Zev Weiss <zev@...ilderbeest.net>,
	Ondrej Mosnacek <omosnace@...hat.com>,
	Miguel Ojeda <ojeda@...nel.org>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Asahi Linux <asahi@...ts.linux.dev>
Subject: Re: [PATCH 0/4] arm64: Support the TSO memory model

Hi Hector,

On Thu, Apr 11, 2024 at 09:51:19AM +0900, Hector Martin wrote:
> x86 CPUs implement a stricter memory modern than ARM64 (TSO). For this
> reason, x86 emulation on baseline ARM64 systems requires very expensive
> memory model emulation. Having hardware that supports this natively is
> therefore very attractive. Such hardware, in fact, exists. This series
> adds support for userspace to identify when TSO is available and
> toggle it on, if supported.

I'm probably going to make myself hugely unpopular here, but I have a
strong objection to this patch series as it stands. I firmly believe
that providing a prctl() to query and toggle the memory model to/from
TSO is going to lead to subtle fragmentation of arm64 Linux userspace.

It's not difficult to envisage this TSO switch being abused for native
arm64 applications:

  * A program no longer crashes when TSO is enabled, so the developer
    just toggles TSO to meet a deadline.

  * Some legacy x86 sources are being ported to arm64 but concurrency
    is hard so the developer just enables TSO to (mostly) avoid thinking
    about it.

  * Some binaries in a distribution exhibit instability which goes away
    in TSO mode, so a taskset-like program is used to run them with TSO
    enabled.

In all these cases, we end up with native arm64 applications that will
either fail to load or will crash in subtle ways on CPUs without the TSO
feature. Assuming that the application cannot be fixed, a better
approach would be to recompile using stronger instructions (e.g.
LDAR/STLR) so that at least the resulting binary is portable. Now, it's
true that some existing CPUs are TSO by design (this is a perfectly
valid implementation of the arm64 memory model), but I think there's a
big difference between quietly providing more ordering guarantees than
software may be relying on and providing a mechanism to discover,
request and ultimately rely upon the stronger behaviour.

An alternative option is to go down the SPARC RMO route and just enable
TSO statically (although presumably in the firmware) for Apple silicon.
I'm assuming that has a performance impact for native code?

Will

P.S. I briefly pondered the idea of the kernel toggling the bit in the
ELF loader when e.g. it sees an x86 machine type but I suspect that
doesn't really help with existing emulators and you'd still need a way
to tell the emulator whether or not it was enabled.

Powered by blists - more mailing lists