All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Will Deacon <will@kernel.org>
Cc: Zayd Qumsieh <zayd_qumsieh@apple.com>,
	Hector Martin <marcan@marcan.st>, Marc Zyngier <maz@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Justin Lu <ih_justin@apple.com>,
	Ryan Houdek <Houdek.Ryan@fex-emu.org>,
	Mark Brown <broonie@kernel.org>, Ard Biesheuvel <ardb@kernel.org>,
	Mateusz Guzik <mjguzik@gmail.com>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	Oliver Upton <oliver.upton@linux.dev>,
	Miguel Luis <miguel.luis@oracle.com>,
	Joey Gouly <joey.gouly@arm.com>,
	Christoph Paasch <cpaasch@apple.com>,
	Kees Cook <keescook@chromium.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Baoquan He <bhe@redhat.com>,
	Joel Granados <j.granados@samsung.com>,
	Dawei Li <dawei.li@shingroup.cn>,
	Andrew Morton <akpm@linux-foundation.org>,
	Florent Revest <revest@chromium.org>,
	David Hildenbrand <david@redhat.com>,
	Stefan Roesch <shr@devkernel.io>,
	Andy Chiu <andy.chiu@sifive.com>,
	Josh Triplett <josh@joshtriplett.org>,
	Oleg Nesterov <oleg@redhat.com>, Helge Deller <deller@gmx.de>,
	Zev Weiss <zev@bewilderbeest.net>,
	Ondrej Mosnacek <omosnace@redhat.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Asahi Linux <asahi@lists.linux.dev>
Subject: Re: [PATCH 0/4] arm64: Support the TSO memory model
Date: Fri, 19 Apr 2024 19:05:12 +0100	[thread overview]
Message-ID: <ZiKyWGKTw6Aqntod@arm.com> (raw)
In-Reply-To: <20240419165826.GB4020@willie-the-truck>

On Fri, Apr 19, 2024 at 05:58:26PM +0100, Will Deacon wrote:
> On Mon, Apr 15, 2024 at 07:22:41PM -0700, Zayd Qumsieh wrote:
> > >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 definitely not our intent to fragment the ecosystem. The goal
> > of this memory ordering is to simplify emulation layers that benefit
> > from this. If you have suggestions to reduce the risk of it being
> > misused outside of emulators, we'd be happy to look into it.
> 
> Once you have exposed this toggle via prctl(), it doesn't really matter
> what your intentions where. It will get used outside of emulation laters
> and we'll be stuck supporting it.

Just FTR, I fully agree with Will. I'm strongly against this kind of ABI
for a non-architected, implementation defined feature. I can't even tell
exactly what TSO means on the Apple hardware. Is it close to the x86
TSO? Is there a formal memory model for it? Are future Apple (or other
Arm vendor) implementations going to follow exactly the same model to be
able to call it some form of "Apple standard" that deserves an ABI?

So, sorry, I'm going to NAK these approaches proposing imp def features
as generic opt-in mechanisms (the microVMs thing sounds doable though,
to my limited understanding; I guess that would mean running the
emulator in a VM).

-- 
Catalin

WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Will Deacon <will@kernel.org>
Cc: Zayd Qumsieh <zayd_qumsieh@apple.com>,
	Hector Martin <marcan@marcan.st>, Marc Zyngier <maz@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Justin Lu <ih_justin@apple.com>,
	Ryan Houdek <Houdek.Ryan@fex-emu.org>,
	Mark Brown <broonie@kernel.org>, Ard Biesheuvel <ardb@kernel.org>,
	Mateusz Guzik <mjguzik@gmail.com>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	Oliver Upton <oliver.upton@linux.dev>,
	Miguel Luis <miguel.luis@oracle.com>,
	Joey Gouly <joey.gouly@arm.com>,
	Christoph Paasch <cpaasch@apple.com>,
	Kees Cook <keescook@chromium.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Baoquan He <bhe@redhat.com>,
	Joel Granados <j.granados@samsung.com>,
	Dawei Li <dawei.li@shingroup.cn>,
	Andrew Morton <akpm@linux-foundation.org>,
	Florent Revest <revest@chromium.org>,
	David Hildenbrand <david@redhat.com>,
	Stefan Roesch <shr@devkernel.io>,
	Andy Chiu <andy.chiu@sifive.com>,
	Josh Triplett <josh@joshtriplett.org>,
	Oleg Nesterov <oleg@redhat.com>, Helge Deller <deller@gmx.de>,
	Zev Weiss <zev@bewilderbeest.net>,
	Ondrej Mosnacek <omosnace@redhat.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Asahi Linux <asahi@lists.linux.dev>
Subject: Re: [PATCH 0/4] arm64: Support the TSO memory model
Date: Fri, 19 Apr 2024 19:05:12 +0100	[thread overview]
Message-ID: <ZiKyWGKTw6Aqntod@arm.com> (raw)
In-Reply-To: <20240419165826.GB4020@willie-the-truck>

On Fri, Apr 19, 2024 at 05:58:26PM +0100, Will Deacon wrote:
> On Mon, Apr 15, 2024 at 07:22:41PM -0700, Zayd Qumsieh wrote:
> > >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 definitely not our intent to fragment the ecosystem. The goal
> > of this memory ordering is to simplify emulation layers that benefit
> > from this. If you have suggestions to reduce the risk of it being
> > misused outside of emulators, we'd be happy to look into it.
> 
> Once you have exposed this toggle via prctl(), it doesn't really matter
> what your intentions where. It will get used outside of emulation laters
> and we'll be stuck supporting it.

Just FTR, I fully agree with Will. I'm strongly against this kind of ABI
for a non-architected, implementation defined feature. I can't even tell
exactly what TSO means on the Apple hardware. Is it close to the x86
TSO? Is there a formal memory model for it? Are future Apple (or other
Arm vendor) implementations going to follow exactly the same model to be
able to call it some form of "Apple standard" that deserves an ABI?

So, sorry, I'm going to NAK these approaches proposing imp def features
as generic opt-in mechanisms (the microVMs thing sounds doable though,
to my limited understanding; I guess that would mean running the
emulator in a VM).

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2024-04-19 18:05 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-11  0:51 [PATCH 0/4] arm64: Support the TSO memory model Hector Martin
2024-04-11  0:51 ` Hector Martin
2024-04-11  0:51 ` [PATCH 1/4] prctl: Introduce PR_{SET,GET}_MEM_MODEL Hector Martin
2024-04-11  0:51   ` Hector Martin
2024-04-11  0:51 ` [PATCH 2/4] arm64: Implement PR_{GET,SET}_MEM_MODEL for always-TSO CPUs Hector Martin
2024-04-11  0:51   ` Hector Martin
2024-04-11  0:51 ` [PATCH 3/4] arm64: Introduce scaffolding to add ACTLR_EL1 to thread state Hector Martin
2024-04-11  0:51   ` Hector Martin
2024-04-11  0:51 ` [PATCH 4/4] arm64: Implement Apple IMPDEF TSO memory model control Hector Martin
2024-04-11  0:51   ` Hector Martin
2024-04-11  1:37 ` [PATCH 0/4] arm64: Support the TSO memory model Neal Gompa
2024-04-11  1:37   ` Neal Gompa
2024-04-11 13:28 ` Will Deacon
2024-04-11 13:28   ` Will Deacon
2024-04-11 14:19   ` Hector Martin
2024-04-11 14:19     ` Hector Martin
2024-04-11 18:43     ` Hector Martin
2024-04-11 18:43       ` Hector Martin
2024-04-16  2:22       ` Zayd Qumsieh
2024-04-16  2:22         ` Zayd Qumsieh
2024-04-19 16:58         ` Will Deacon
2024-04-19 16:58           ` Will Deacon
2024-04-19 18:05           ` Catalin Marinas [this message]
2024-04-19 18:05             ` Catalin Marinas
2024-04-19 16:58     ` Will Deacon
2024-04-19 16:58       ` Will Deacon
2024-04-20 11:37       ` Marc Zyngier
2024-04-20 11:37         ` Marc Zyngier
2024-05-02  0:10         ` Zayd Qumsieh
2024-05-02  0:10           ` Zayd Qumsieh
2024-05-02 13:25           ` Marc Zyngier
2024-05-02 13:25             ` Marc Zyngier
2024-05-06  8:20             ` Jonas Oberhauser
2024-05-06  8:20               ` Jonas Oberhauser
2024-04-20 12:13       ` Eric Curtin
2024-04-20 12:13         ` Eric Curtin
2024-04-20 12:15         ` Eric Curtin
2024-04-20 12:15           ` Eric Curtin
2024-05-06 11:21         ` Sergio Lopez Pascual
2024-05-06 11:21           ` Sergio Lopez Pascual
2024-05-06 16:12           ` Marc Zyngier
2024-05-06 16:12             ` Marc Zyngier
2024-05-06 16:20             ` Eric Curtin
2024-05-06 16:20               ` Eric Curtin
2024-05-06 22:04             ` Sergio Lopez Pascual
2024-05-06 22:04               ` Sergio Lopez Pascual
2024-05-02  0:16   ` Zayd Qumsieh
2024-05-02  0:16     ` Zayd Qumsieh
2024-05-07 10:24   ` Alex Bennée
2024-05-07 10:24     ` Alex Bennée
2024-05-07 14:52     ` Ard Biesheuvel
2024-05-07 14:52       ` Ard Biesheuvel
2024-05-09 11:13       ` Catalin Marinas
2024-05-09 11:13         ` Catalin Marinas
2024-05-09 12:31         ` Neal Gompa
2024-05-09 12:31           ` Neal Gompa
2024-05-09 12:56           ` Catalin Marinas
2024-05-09 12:56             ` Catalin Marinas
2024-04-16  2:11 ` Zayd Qumsieh
2024-04-16  2:11   ` Zayd Qumsieh

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=ZiKyWGKTw6Aqntod@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=Houdek.Ryan@fex-emu.org \
    --cc=akpm@linux-foundation.org \
    --cc=andy.chiu@sifive.com \
    --cc=anshuman.khandual@arm.com \
    --cc=ardb@kernel.org \
    --cc=asahi@lists.linux.dev \
    --cc=bhe@redhat.com \
    --cc=broonie@kernel.org \
    --cc=cpaasch@apple.com \
    --cc=david@redhat.com \
    --cc=dawei.li@shingroup.cn \
    --cc=deller@gmx.de \
    --cc=ih_justin@apple.com \
    --cc=j.granados@samsung.com \
    --cc=joey.gouly@arm.com \
    --cc=josh@joshtriplett.org \
    --cc=keescook@chromium.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcan@marcan.st \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=miguel.luis@oracle.com \
    --cc=mjguzik@gmail.com \
    --cc=ojeda@kernel.org \
    --cc=oleg@redhat.com \
    --cc=oliver.upton@linux.dev \
    --cc=omosnace@redhat.com \
    --cc=revest@chromium.org \
    --cc=samitolvanen@google.com \
    --cc=shr@devkernel.io \
    --cc=will@kernel.org \
    --cc=zayd_qumsieh@apple.com \
    --cc=zev@bewilderbeest.net \
    /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.