From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 63143130AC4; Fri, 19 Apr 2024 18:05:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713549920; cv=none; b=GEM1zCmLsVhvquHbIKe0tUyaWmeRMyZ3uGIekgdAR72WAFt1+SKJTXmJon5RiiVFWJ3bGBKUe+OFrmU5IuuX14SQQ4VAUJFZ9fnjdHeGZcFnF0o/6EbH33mOtZo1KEQr8bH8ducmxL7gacnevUS3YSHodlKqvGRx1x3dBcmoBz0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713549920; c=relaxed/simple; bh=UEVFeS+/tMCw0E76rQZ5tWlTwk4nDLScKXAuUGbS/4Q=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=a+CmthJMEQITN3wMyFh4o882A2xCXEjXUpivdDlbgnMN4GUoddRnEVmblRXlhXyDJs1hAVuvYLPhKL1JNS3kXPp/0pFQozXITuB4p2XHsFKkHZCKxMjyfRFX9rHNKOcvONBG86fhbhIaA5g+TOqnNgtGM0tvpm6bcXhNJAEAJD0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2CC5CC116B1; Fri, 19 Apr 2024 18:05:13 +0000 (UTC) Date: Fri, 19 Apr 2024 19:05:12 +0100 From: Catalin Marinas To: Will Deacon Cc: Zayd Qumsieh , Hector Martin , Marc Zyngier , Mark Rutland , Justin Lu , Ryan Houdek , Mark Brown , Ard Biesheuvel , Mateusz Guzik , Anshuman Khandual , Oliver Upton , Miguel Luis , Joey Gouly , Christoph Paasch , Kees Cook , Sami Tolvanen , Baoquan He , Joel Granados , Dawei Li , Andrew Morton , Florent Revest , David Hildenbrand , Stefan Roesch , Andy Chiu , Josh Triplett , Oleg Nesterov , Helge Deller , Zev Weiss , Ondrej Mosnacek , Miguel Ojeda , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Asahi Linux Subject: Re: [PATCH 0/4] arm64: Support the TSO memory model Message-ID: References: <20240416022242.89623-1-zayd_qumsieh@apple.com> <20240419165826.GB4020@willie-the-truck> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9F31EC04FF6 for ; Fri, 19 Apr 2024 18:05:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=JrklYpAmc6atiXhwmXtohT8YyoiPM21Xfb/oxxnUJXk=; b=Tc0d4xl2rtBVWt eIxfBR9YohdIlXrdxdTkqWe4mtlrDfqMmcwJgzVSSjnNcxWSA95VeBqcBkqBHRGDEJykLhNx3V+O2 sYkfW0NVvaF+iNtPVmcncCbrJVM1fsXpy0kXfXr96CelJ+1pd9BjIEeaOBRiGweN6i3InPNxh1fT7 4dj8tzmF9SKCaGRhWrzN7ABoszBEV4uT9MKpfdDwLy/meZpo2rMifnQwziWq+nQgdSn1y9BkpFOeu kCtXdp97OqYsqhZBcQhUwleAtogNhkasj1F3LxzMHswMVoZIkx1+LeimjFLd7GkbyFhCLIDnJovLn fCHpCwK0PB8WewmAxkzg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rxsc1-00000006brv-3Ueg; Fri, 19 Apr 2024 18:05:25 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rxsby-00000006bqR-3Z9M for linux-arm-kernel@lists.infradead.org; Fri, 19 Apr 2024 18:05:24 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 479D061A7F; Fri, 19 Apr 2024 18:05:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2CC5CC116B1; Fri, 19 Apr 2024 18:05:13 +0000 (UTC) Date: Fri, 19 Apr 2024 19:05:12 +0100 From: Catalin Marinas To: Will Deacon Cc: Zayd Qumsieh , Hector Martin , Marc Zyngier , Mark Rutland , Justin Lu , Ryan Houdek , Mark Brown , Ard Biesheuvel , Mateusz Guzik , Anshuman Khandual , Oliver Upton , Miguel Luis , Joey Gouly , Christoph Paasch , Kees Cook , Sami Tolvanen , Baoquan He , Joel Granados , Dawei Li , Andrew Morton , Florent Revest , David Hildenbrand , Stefan Roesch , Andy Chiu , Josh Triplett , Oleg Nesterov , Helge Deller , Zev Weiss , Ondrej Mosnacek , Miguel Ojeda , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Asahi Linux Subject: Re: [PATCH 0/4] arm64: Support the TSO memory model Message-ID: References: <20240416022242.89623-1-zayd_qumsieh@apple.com> <20240419165826.GB4020@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240419165826.GB4020@willie-the-truck> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240419_110522_955327_4F82368A X-CRM114-Status: GOOD ( 21.75 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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