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 466C5C433EF for ; Thu, 28 Oct 2021 09:06:37 +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 0F08861056 for ; Thu, 28 Oct 2021 09:06:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 0F08861056 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com 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=XS0nIlB7geSbpyeNnnlPor15pB3hJGOOaECqVVl4HKk=; b=d9Ts3lbsifzdjz yFaOTXDzQH5nrT6OyoekDbfRb8M165bWasO9YYgE9errW/79T9aaIH+P7r9kE6Mhmrd9bw0IL8Xxl Yld0M5FQ15G8GFA2OqqukHAE8QwzyS/Af9L5wB+kMIDLW8L8fpsbYvNrFXadQ9WQaUzpMAecYhkk3 YEeKW4/Wtb1FXeKL2DDsl/LUJicRz+anLclWnIQbeg1PsGy3NiQtY9orueC8uwHXvtpk/akK0oxnH 3OLzLH2XdFXdnrAO2DrVDI6gRKQPbTIOFpfO5inQTiy1rpUauRNYcsmcYjyFdHW6onfOmzrXA/Ogv qGjUNKd49eM2ihPqS6ew==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mg1K2-007KsY-3Y; Thu, 28 Oct 2021 09:03:42 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mg1Jy-007KsE-3b for linux-arm-kernel@lists.infradead.org; Thu, 28 Oct 2021 09:03:39 +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 A62611FB; Thu, 28 Oct 2021 02:03:34 -0700 (PDT) Received: from C02TD0UTHF1T.local (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1907D3F5A1; Thu, 28 Oct 2021 02:03:31 -0700 (PDT) Date: Thu, 28 Oct 2021 10:03:07 +0100 From: Mark Rutland To: Will Deacon 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: <20211028090307.GA74067@C02TD0UTHF1T.local> References: <20211026034844.1393437-1-reijiw@google.com> <0cd301eb-c2a4-bc90-46b8-cb4d4e25978b@arm.com> <20211026122300.GB34073@C02TD0UTHF1T.local> <20211027110947.GB51402@C02TD0UTHF1T.local> <20211028074609.GA23476@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20211028074609.GA23476@willie-the-truck> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211028_020338_274243_7AFBB2A7 X-CRM114-Status: GOOD ( 37.03 ) 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 Thu, Oct 28, 2021 at 08:46:10AM +0100, Will Deacon wrote: > 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. TBH, I think trapping DC ZVA rather than forcing it to be UNDEF was an architectural mistake. I think the intent of the "prohibited" wording (and exposure of DCZID_EL0.DZP to EL0 and EL1) is clearly that SW should *avoid* DC ZVA and friends when DCZID_EL0.DZP is set (and libc and the Arm optimized routines have *always* checked that), and performance would be abysmal with emulated DC ZVA, so at minimum we want to avoid hitting emulation in the common case. > We could document *that* though? I guess; though it makes me uneasy since the architecture clearly pushes people to read CTR_EL0.DZP, and heavily implies that there's no need to emulate, so I don't think we have much of a leg to stand on from an architecture PoV. If we need to support this, my preference would be to support DCZID_EL0.DZP==1 by avoiding the trapped instructions entirely. I realise the problem as ever is "what does userspace do?". Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel