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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 417E7C433EF for ; Thu, 28 Oct 2021 07:47:35 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id E85F0610FD for ; Thu, 28 Oct 2021 07:47:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org E85F0610FD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org 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=Q6G1dBL3NVM0HmBVzJ3+rs1+rS4NNdpYbr7VUctKqFI=; b=WRRkjbIW0NM6u8 4Z827VmXwkfn7meOO0HB/ROKDNW4TKKeXAmYveryW/M5fXkDzb/kHeXyfBb4B4ZwBzhMyhwtEtXOV 8mfwkd/0uf32bvzZROGYr/QONhQ+p5ML/NCLdHPJpWMTBK6J6NfL1dMjmlprIr+SK1+plSdhK+bh4 RFwWsbXdG0DnK781YivuI/zmJ/j+uSKKYHdnGsQVTlsoHeEI7KHYkU8ZioRKnI1VSVoVc5teeP/et paHZvu/zLqKes+WbkNcp8zxWrwgfeZdMAnywCTGzWj2t+5hUFS2TVjYhYpGxUAF7Ju9fD6yPTx2UF /6TGS9Ie8RPqACJACcGA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mg079-0078ct-8v; Thu, 28 Oct 2021 07:46:19 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mg076-0078cP-2K for linux-arm-kernel@lists.infradead.org; Thu, 28 Oct 2021 07:46:17 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 5EF6761100; Thu, 28 Oct 2021 07:46:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1635407175; bh=DPimGRQJ8XfpZ7zjZp/fIiAzCXm5mmuAnmJnT3rhELA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=goJfFKx0LqQvIyXAmibZlXcYqWE2BLUjA4b+3jItZtR6WjOyPmEt96nLhvx+hUHmz DQH3fukJOOEyrfVO851gst2LPnHRxgan44YOelNAzUyevjTW+FWLzTL7MiT0LjophU CzQumx4Sy1v8DXF2tbtEbU0MsP5toKuuQcSRprazpo2U2SonFF8FnnLofv+ITRNOj2 6rYwHp2HzJ5ZJ00/eRw/MTraCQQ17BDwFBQ9Giy925y5yuN7dF4mGoLLi/2uZlFNaz dVeJIBv82WP7aKitlzFslt10jh6O0yUj9TfyRh1USEabMsl0WwvGgMz2F4b/XcAXXK l3UBOhoxFUCUQ== Date: Thu, 28 Oct 2021 08:46:10 +0100 From: Will Deacon To: Mark Rutland Cc: Reiji Watanabe , Robin Murphy , Catalin Marinas , Marc Zyngier , linux-arm-kernel@lists.infradead.org, Peter Shier , Ricardo Koller , Oliver Upton , Jing Zhang , Raghavendra Rao Anata Subject: Re: [PATCH] arm64: clear_page() shouldn't use DC ZVA when DCZID_EL0.DZP == 1 Message-ID: <20211028074609.GA23476@willie-the-truck> References: <20211026034844.1393437-1-reijiw@google.com> <0cd301eb-c2a4-bc90-46b8-cb4d4e25978b@arm.com> <20211026122300.GB34073@C02TD0UTHF1T.local> <20211027110947.GB51402@C02TD0UTHF1T.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20211027110947.GB51402@C02TD0UTHF1T.local> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211028_004616_198454_B5688238 X-CRM114-Status: GOOD ( 30.84 ) 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 Wed, Oct 27, 2021 at 12:09:47PM +0100, Mark Rutland wrote: > On Tue, Oct 26, 2021 at 11:44:51PM -0700, Reiji Watanabe wrote: > > On Tue, Oct 26, 2021 at 5:23 AM Mark Rutland wrote: > > > On Tue, Oct 26, 2021 at 12:22:20PM +0100, Robin Murphy wrote: > > > > On 2021-10-26 04:48, Reiji Watanabe wrote: > > > > > Currently, clear_page() uses DC ZVA instruction unconditionally. But it > > > > > should make sure that DCZID_EL0.DZP, which indicates whether or not use > > > > > of DC ZVA instruction is prohibited, is zero when using the instruction. > > > > > Use stp as memset does instead when DCZID_EL0.DZP == 1. > > > > > > > > > > Signed-off-by: Reiji Watanabe > > > > > --- > > > > > arch/arm64/lib/clear_page.S | 11 +++++++++++ > > > > > 1 file changed, 11 insertions(+) > > > > > > > > > > diff --git a/arch/arm64/lib/clear_page.S b/arch/arm64/lib/clear_page.S > > > > > index b84b179edba3..7ce1bfa4081c 100644 > > > > > --- a/arch/arm64/lib/clear_page.S > > > > > +++ b/arch/arm64/lib/clear_page.S > > > > > @@ -16,6 +16,7 @@ > > > > > */ > > > > > SYM_FUNC_START_PI(clear_page) > > > > > mrs x1, dczid_el0 > > > > > + tbnz x1, #4, 2f /* Branch if DC GVA is prohibited */ > > > > > > DCZID_EL0.DZP (AKA DCZID_EL0[4]) says whether all of DC {ZVA,GVA,GZVA} > > > are prohibited. This loop uses DZ ZVA, not GC GVA, so it'd be nice to > > > s/GVA/ZVA/ here. > > > > Thank you for catching it ! I will fix that. > > > > > Howver, `DC GVA` and `DC GZVA` are both used in mte_set_mem_tag_range(), > > > which'll need a similar update... > > > > Yes, I'm aware of that and mte_zero_clear_page_tags() needs to get > > updated as well. But, Since I'm not familiar with MTE (and I don't > > have any plans to use MTE yet), I didn't work on them (I'm not sure > > how I can test them). > > I might try to fix them separately later as well when I have time > > (not so soon most likely though). > > My view is that we should either: > > * Document that we require DCZID_EL0.DZP==0, as is implicitly the case > today. I disagree with that. There's nothing wrong in trapping this stuff, as long as you go ahead and emulate it, which is exactly why we aren't checking it at the moment as EL2 should be prepared to handle the trap. The Arm ARM talks about the instructions being "prohibited" but that doesn't mean anything -- the reality is that they trap to EL2. We could document *that* though? Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel