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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2BEE8C433DB for ; Mon, 18 Jan 2021 14:17:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D21DC22B39 for ; Mon, 18 Jan 2021 14:17:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2392844AbhARORZ (ORCPT ); Mon, 18 Jan 2021 09:17:25 -0500 Received: from foss.arm.com ([217.140.110.172]:36868 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2392705AbhAROPY (ORCPT ); Mon, 18 Jan 2021 09:15:24 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7772A1FB; Mon, 18 Jan 2021 06:14:36 -0800 (PST) Received: from C02TD0UTHF1T.local (unknown [10.57.39.202]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 08AA53F68F; Mon, 18 Jan 2021 06:14:32 -0800 (PST) Date: Mon, 18 Jan 2021 14:14:29 +0000 From: Mark Rutland To: Vincenzo Frascino Cc: Catalin Marinas , Branislav Rankov , Marco Elver , Andrey Konovalov , Evgenii Stepanov , linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, Alexander Potapenko , linux-arm-kernel@lists.infradead.org, Andrey Ryabinin , Will Deacon , Dmitry Vyukov Subject: Re: [PATCH v3 3/4] arm64: mte: Enable async tag check fault Message-ID: <20210118141429.GC31263@C02TD0UTHF1T.local> References: <20210115120043.50023-1-vincenzo.frascino@arm.com> <20210115120043.50023-4-vincenzo.frascino@arm.com> <20210118125715.GA4483@gaia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 18, 2021 at 01:37:35PM +0000, Vincenzo Frascino wrote: > On 1/18/21 12:57 PM, Catalin Marinas wrote: > >> + if (tfsr_el1 & SYS_TFSR_EL1_TF1) { > >> + write_sysreg_s(0, SYS_TFSR_EL1); > >> + isb(); > > While in general we use ISB after a sysreg update, I haven't convinced > > myself it's needed here. There's no side-effect to updating this reg and > > a subsequent TFSR access should see the new value. > > Why there is no side-effect? Catalin's saying that the value of TFSR_EL1 doesn't affect anything other than a read of TFSR_EL1, i.e. there are no indirect reads of TFSR_EL1 where the value has an effect, so there are no side-effects. Looking at the ARM ARM, no synchronization is requires from a direct write to an indirect write (per ARM DDI 0487F.c table D13-1), so I agree that we don't need the ISB here so long as there are no indirect reads. Are you aware of cases where the TFSR_EL1 value is read other than by an MRS? e.g. are there any cases where checks are elided if TF1 is set? If so, we may need the ISB to order the direct write against subsequent indirect reads. Thanks, Mark. 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 X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A4EEFC433DB for ; Mon, 18 Jan 2021 14:16:23 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 489AA22B39 for ; Mon, 18 Jan 2021 14:16:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 489AA22B39 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject: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=xzqfYDvpr3al7tt6o/Sk7SLUoFJCw59xD/zl+0oqVd0=; b=ynhA2OLAIdU33yo9zloUNDToG i3T9lLGRxcTL6HxNyovggDR4gmXgMOrfdGHFAQq8J8fWSCMoepvKn9DqiBn+0eySEUpVlzX4tBSCj sOm5NhqgHJfMkOzbIE6vmTf+/Lk1Zm3kZPgui3eX/8rv+GH8XAANoDa3iho5YD+gnV1HWb9bpn9dw CcKRNu1hky6HlAuAWc7F/04vasErCj1+MErVj11OfGTldJv6Ep8lxvANSJ90R/4JOAwyqpXFTQtTU mDVNLzZJUgXIyip1Rh0cPhtlPw9NsZPGlgrkymU2cKfpt50B0veLyZpdHRxa73rN1EyP3stRkGoo4 mzRshJLAQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l1VIt-00068m-IR; Mon, 18 Jan 2021 14:14:47 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l1VIp-00068R-CR for linux-arm-kernel@lists.infradead.org; Mon, 18 Jan 2021 14:14:44 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7772A1FB; Mon, 18 Jan 2021 06:14:36 -0800 (PST) Received: from C02TD0UTHF1T.local (unknown [10.57.39.202]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 08AA53F68F; Mon, 18 Jan 2021 06:14:32 -0800 (PST) Date: Mon, 18 Jan 2021 14:14:29 +0000 From: Mark Rutland To: Vincenzo Frascino Subject: Re: [PATCH v3 3/4] arm64: mte: Enable async tag check fault Message-ID: <20210118141429.GC31263@C02TD0UTHF1T.local> References: <20210115120043.50023-1-vincenzo.frascino@arm.com> <20210115120043.50023-4-vincenzo.frascino@arm.com> <20210118125715.GA4483@gaia> 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-20210118_091444_298825_A65B9777 X-CRM114-Status: GOOD ( 13.89 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Branislav Rankov , Will Deacon , Catalin Marinas , linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, Alexander Potapenko , linux-arm-kernel@lists.infradead.org, Andrey Konovalov , Dmitry Vyukov , Andrey Ryabinin , Marco Elver , Evgenii Stepanov 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 Mon, Jan 18, 2021 at 01:37:35PM +0000, Vincenzo Frascino wrote: > On 1/18/21 12:57 PM, Catalin Marinas wrote: > >> + if (tfsr_el1 & SYS_TFSR_EL1_TF1) { > >> + write_sysreg_s(0, SYS_TFSR_EL1); > >> + isb(); > > While in general we use ISB after a sysreg update, I haven't convinced > > myself it's needed here. There's no side-effect to updating this reg and > > a subsequent TFSR access should see the new value. > > Why there is no side-effect? Catalin's saying that the value of TFSR_EL1 doesn't affect anything other than a read of TFSR_EL1, i.e. there are no indirect reads of TFSR_EL1 where the value has an effect, so there are no side-effects. Looking at the ARM ARM, no synchronization is requires from a direct write to an indirect write (per ARM DDI 0487F.c table D13-1), so I agree that we don't need the ISB here so long as there are no indirect reads. Are you aware of cases where the TFSR_EL1 value is read other than by an MRS? e.g. are there any cases where checks are elided if TF1 is set? If so, we may need the ISB to order the direct write against subsequent indirect reads. Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel