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 F225FC10F1A for ; Thu, 9 May 2024 11:14:04 +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=beNH9bXIbAAEW/hetP0ce1QXUGOXp5QcrM5mrqre7SQ=; b=SXCIZrdoIDuYqT PHrHmobDyjTHTA++6JzYhvMpLA+/lBdNYjiPxjzQorrDoTAs8oVL8C6MPcpy8aBCl9vc+P/KMvd1v JCvLH8tMkGkBlIXa8WJfdyYeju9J+iQT24gvGLX9sQeq8RmWrywD/+DC1TXXNxwWm8yVlBPG2wTpm KRNSFZciZvNmRjeomd+zQ9mJng0wetwq8bJ4waPcyZNCrhcTtnt9onuaunst2iVL0l60zzD0pBSVe qe6CDRL9ulL0L8Sc276Up9O+5bvTskgHVyTczltp5GqyhMCZqHS87szxmnfcPkvQ5grEUjg+X5ite KhlpB1QVpWEZ9fW9SgvQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s51ic-00000001F7U-0Ej7; Thu, 09 May 2024 11:13:46 +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 1s51iY-00000001F6t-3WMA for linux-arm-kernel@lists.infradead.org; Thu, 09 May 2024 11:13:44 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id A275461D13; Thu, 9 May 2024 11:13:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 21B24C116B1; Thu, 9 May 2024 11:13:33 +0000 (UTC) Date: Thu, 9 May 2024 12:13:31 +0100 From: Catalin Marinas To: Ard Biesheuvel Cc: Alex =?iso-8859-1?Q?Benn=E9e?= , Will Deacon , Hector Martin , Marc Zyngier , Mark Rutland , Zayd Qumsieh , Justin Lu , Ryan Houdek , Mark Brown , 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: <20240411-tso-v1-0-754f11abfbff@marcan.st> <20240411132853.GA26481@willie-the-truck> <87seythqct.fsf@draig.linaro.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240509_041343_073851_8A55FF78 X-CRM114-Status: GOOD ( 30.77 ) 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, May 07, 2024 at 04:52:30PM +0200, Ard Biesheuvel wrote: > On Tue, 7 May 2024 at 12:24, Alex Benn=E9e wrote: > > I think the main use case here is for emulation. When we run x86-on-arm > > in QEMU we do currently insert lots of extra barrier instructions on > > every load and store. If we can probe and set a TSO mode I can assure > > you we'll do the right thing ;-) > = > Without a public specification of what TSO mode actually entails, > deciding which of those barriers can be dropped is not going to be as > straight-forward as you make it out to be. > = > Apple's TSO mode is vertically integrated with Rosetta, which means > that TSO mode provides whatever Rosetta needs to run x86 code > correctly, and that it could mean different things on different > generations of the micro-architecture. And whether Apple's TSO is the > same as Fujitsu's is anyone's guess afaik. Indeed. Apart from using impdef registers, that's what I think is the second biggest problem with this feature (and the corresponding patches). We don't know the precise memory model, we can't tell whether this TSO bit is stored in the TLB. If it is, is it per ASID/VMID? The other problem Marc raised is what memory model is between two CPUs where only one has the TSO bit set? Does it only break the TSO model or is there a chance that it also breaks the default relaxed model? What other TSO flavours are out there, how do they compare with the Apple one? > Running a game and seeing it perform better is great, but it is not > the kind of rigor we usually attempt to apply when adding support for > architectural features. Hopefully, there will be some architectural > support for this in the future, but without any spec that defines the > memory model it implements, I am not convinced we should merge this. There is FEAT_LRCPC (available on Apple Silicon from M2 onwards). Rather than having a big knob to turn TSO on or off, this feature introduces instructions that permit a code generator to get the TSO semantics in a more efficient way (e.g. using LDAPR+STLR instead of the stricter LDAR+STLR; not sure how well these are implemented on the Apple Silicon). There are further improvements in FEAT_LRCPC{2,3} (with the latter adding support for SIMD but not available in hardware yet). So the direction from Arm is pretty clear, acknowledging that there is a need for such TSO emulation but not in the way of undocumented impdef registers. Whether more is needed here, I guess people working on emulators could reach out to Arm or CPU vendors with suggestions (the path to the architects is not straightforward, usually legal has a say, but it's doable, there are formal channels already). I see the impdef hardware TSO options as temporary until CPU implementations catch up to architected FEAT_LRCPC*. Given the problems already stated in this thread, I think such hacks should be carried downstream and (hopefully) will eventually vanish. Maybe those TSO knobs currently make an emulation faster than FEAT_LRCPC* but that's feedback to go to the microarchitects on the implementation (or architects on what other instructions should be covered). -- = Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel