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 46AA8C433FE for ; Tue, 15 Nov 2022 11:32:39 +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=JFOME3RwvwhL5W/pczeJb5Nd1eU7SraakOGYFbIKTok=; b=bE/ngduzV7Axno ijWmffKz2e1GxsHaFr7ExAOIYrQ7RCp9i0QAB8jvYFuNvnAxKlW3SuNtMHmeMknaMMsqn1wtXeMmE cKW/lepI2JNet8PB7O99Nz66U3ZsEz4VbOQ/i3gdURKUeqkFnbSg+WAXH4ZoEaL+vXWHyroJjO4cJ vnwJwzoedxnXeXOUQL4T86HN2WTOm0WZ08ValCwR3iZ5Oc72rYvpDk57+XePQ72nFMhHnKh8KJDKB gOvwmbZ+Mz18wNL14oAtrhN3L2H7U/Yc42Awh7obsvgOPyvBQnVyJCiBHDk9qyp+zqQtrC6uI5WeH rpC2q2BViFT+vv0zjzfA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ouuAK-00AcN5-4R; Tue, 15 Nov 2022 11:31:44 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ouuAH-00AcLG-4B for linux-arm-kernel@lists.infradead.org; Tue, 15 Nov 2022 11:31:42 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 8E973616C7; Tue, 15 Nov 2022 11:31:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DE9E4C433C1; Tue, 15 Nov 2022 11:31:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1668511900; bh=rn62bIUKfNDs4qARPw8jT2XBwnVNQ2diPDoNbFA7xA4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KY29oRW2w4aAlkXurwuEG+jqzSnvtn1NDiyN2U07IkVhG5TYvW4jfOtLuDdhjV5ht A9V4+arFWeqC2y0OEzo2yDiL6Q+c81iqkwj00YwQB8mLoDaydNQJgGkMa2W7YisMJS PI5XLYyzvs17nR+o87VHDt0/t/5495n7eBPuhl5CHC6NjinRzhfC+4OnB79gDZIchQ Jf/Ftw55MxSfynsQTaZmakYOq3KtpLHjsdtfghm26SSmync5JPg+gYzkJMsghXJFYB 0Y1rMNIFMvKYNlz6JlWPt+cqwFC4ABNsKalydZtj157OgtNqELlSuga/3yZc4C0c9W 9zZj/3kGkPIqA== Date: Tue, 15 Nov 2022 11:31:35 +0000 From: Will Deacon To: Ard Biesheuvel Cc: Mark Rutland , linux-arm-kernel@lists.infradead.org, linux-efi@vger.kernel.org, keescook@chromium.org, Catalin Marinas , Marc Zyngier Subject: Re: [PATCH v5 0/7] arm64: efi: leave MMU and caches on at boot Message-ID: <20221115113134.GC32523@willie-the-truck> References: <20221108182204.2447664-1-ardb@kernel.org> <20221115111658.GA32523@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: 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-20221115_033141_288600_8E67B509 X-CRM114-Status: GOOD ( 37.64 ) 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 Tue, Nov 15, 2022 at 12:21:55PM +0100, Ard Biesheuvel wrote: > On Tue, 15 Nov 2022 at 12:17, Will Deacon wrote: > > > > On Fri, Nov 11, 2022 at 05:36:19PM +0000, Mark Rutland wrote: > > > On Tue, Nov 08, 2022 at 07:21:57PM +0100, Ard Biesheuvel wrote: > > > > The purpose of this series is to remove any explicit cache maintenance > > > > for coherency during early boot that becomes unnecessary if we simply > > > > retain the cacheable 1:1 mapping of all of system RAM provided by EFI, > > > > and use it to populate the ID map page tables. After setting up this > > > > preliminary ID map, we disable the MMU, drop to EL1, reprogram the MAIR, > > > > TCR and SCTLR registers as before, and proceed as usual, avoiding the > > > > need for any manipulations of memory while the MMU and caches are off. > > > > > > > > The only properties of the firmware provided 1:1 map we rely on is that > > > > it does not require any explicit cache maintenance for coherency, and > > > > that it covers the entire memory footprint of the image, including the > > > > BSS and padding at the end - all else is under control of the kernel > > > > itself, as before. > > > > > > As a high-level thing, I'm still very much not keen on entering the kernel with > > > the MMU on. Given that we have to support booting with the MMU off for !EFI > > > boot (including kexec when EFI is in use), I think this makes it harder to > > > reason about the boot code overall (e.g. due to the conditional maintenance > > > added to head.S), and adds more scope for error, even if it simplifies the EFI > > > stub itself. > > > > As discussed offline, two things that would help the current series are: > > > > (1) Some performance numbers comparing MMU off vs MMU on boot > > > > (2) Use of a separate entry point for the MMU on case, potentially failing > > the boot if the MMU is on and we're not using EFI > > > > Ack. > > But thinking about (2) again, failing the boot is better done at a > time when you can inform the user about it, no? > > IOW, just going into a deadloop really early if you enter the bare > metal entry point with the MMU on is going to be hard to distinguish > from other issues, whereas panicking after the console up is more > likely to help getting the actual issue diagnosed. Agreed. > So perhaps we should panic() instead of warn+taint when this condition > occurs, and do it from an early initcall instead of from setup_arch(). To be honest, and I appreciate that this is unhelpful, but I'm fine with the warn+taint and prefer that to a fatal stop. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel