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=-8.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 6B2B3C433DB for ; Wed, 24 Feb 2021 11:47:34 +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 ECCAE64E60 for ; Wed, 24 Feb 2021 11:47:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ECCAE64E60 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=uh5j6Hug/npd+6YvrRhLyuuz41N1jAabi9iDzJ+XaJQ=; b=MsZJ2Q+kjwbZl32G6Hl9NaawA NJlVWgW1GSNgnoWEzNEUOOnY9ULkM5aGRTIHCJzjzecffIrXBxxJUDkle0OLz1enr76RMwKnyvZX6 onmL6uwBK9FOpimYfyuIj5Hl1ihb4WYMHeA8UXJ79ghDvCpJBZ6XXpR/rRV0TYQOFYoxj/3OtVFqZ K9+DatAvwELL3sMh1/a9Xhm+c2szamoxNM8fVmKn7lvPHI+q3+2vBtKxTC6s8qnFAa7u05IE7R9xg rR/x9A1/LEKa9ssa/HJ3tMfEbw+JaE7qWzxGfsV4J9lScS6Yslnxi+I/OP6o0ntBliP52QCXxWLeD ovUbRkw3g==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1lEsc2-0006IC-W1; Wed, 24 Feb 2021 11:45:51 +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 1lEsc0-0006Hq-VQ for linux-arm-kernel@lists.infradead.org; Wed, 24 Feb 2021 11:45:49 +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 723111FB; Wed, 24 Feb 2021 03:45:45 -0800 (PST) Received: from C02TD0UTHF1T.local (unknown [10.57.52.137]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id AC3FF3F73B; Wed, 24 Feb 2021 03:45:43 -0800 (PST) Date: Wed, 24 Feb 2021 11:45:40 +0000 From: Mark Rutland To: Will Deacon Subject: Re: [PATCH 2/3] arm64: Add missing ISB after invalidating TLB in __primary_switch Message-ID: <20210224114540.GD50741@C02TD0UTHF1T.local> References: <20210224093738.3629662-1-maz@kernel.org> <20210224093738.3629662-3-maz@kernel.org> <20210224110506.GA50741@C02TD0UTHF1T.local> <20210224111648.GA11554@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210224111648.GA11554@willie-the-truck> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210224_064549_117014_D42EC069 X-CRM114-Status: GOOD ( 26.82 ) 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: Marc Zyngier , Guillaume Tucker , Catalin Marinas , kernel-team@android.com, Ard Biesheuvel , linux-arm-kernel@lists.infradead.org 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, Feb 24, 2021 at 11:16:50AM +0000, Will Deacon wrote: > On Wed, Feb 24, 2021 at 11:06:43AM +0000, Mark Rutland wrote: > > On Wed, Feb 24, 2021 at 09:37:37AM +0000, Marc Zyngier wrote: > > > Although there has been a bit of back and forth on the subject, > > > it appears that invalidating TLBs requires an ISB instruction > > > after the TLBI/DSB sequence, as documented in d0b7a302d58a > > > ("Revert "arm64: Remove unnecessary ISBs from set_{pte,pmd,pud}""). > > > > That commit describes a different scenario (going faulting->valid > > without TLB maintenance), and I don't think that implies anything about > > the behaviour in the presence of a TLBI, which is quite different. > > Sorry, that was my fault. I remember this all happened around the same > time. > > > Howerver, I do see that commits: > > > > 7f0b1bf045113489 ("arm64: Fix barriers used for page table modifications") > > 51696d346c49c6cf ("arm64: tlb: Ensure we execute an ISB following walk cache invalidation") > > > > ... assume that we need an ISB after a TLBI+DSB, so I think it would be > > better to refer to those, to avoid conflating the distinct cases. > > > > > Add the missing ISB in __primary_switch, just in case. > > > > > > Fixes: 3c5e9f238bc4 ("arm64: head.S: move KASLR processing out of __enable_mmu()") > > > Suggested-by: Will Deacon > > > Signed-off-by: Marc Zyngier > > > > For consistency with the other kernel TLBI paths, I'm fine with this > > (assuming we update the commit message accordingly): > > > > Acked-by: Mark Rutland > > > > My understanding is that we don't need an ISB after invalidation, and if > > we align on that understanding we can follow up and update all of the > > TLBI paths in one go. > > Without FEAT_ETS, I think the ISB is required to complete TLBI: > > | In an implementation that does not implement FEAT_ETS, a TLB maintenance > | instruction executed by a PE, PEx, can complete at any time after it is > | issued, but is only guaranteed to be finished for a PE, PEx, after the > | execution of DSB by the PEx followed by a Context synchronization event. Ah; given that quote, I agree. Can we put that in the commit message? I think that's clearer than referring to any commit, and with that my ack definitely stands. I /hope/ that quote means the same PEx in both cases (i.e. only the issuing PE needs the context synchronization event), or we have much greater problems! Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel