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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 52C6DC433FE for ; Tue, 15 Nov 2022 11:22:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238359AbiKOLWO (ORCPT ); Tue, 15 Nov 2022 06:22:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60222 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238308AbiKOLWM (ORCPT ); Tue, 15 Nov 2022 06:22:12 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5C3A6FFF for ; Tue, 15 Nov 2022 03:22:11 -0800 (PST) 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 ams.source.kernel.org (Postfix) with ESMTPS id 139A5B818BC for ; Tue, 15 Nov 2022 11:22:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C2818C433C1 for ; Tue, 15 Nov 2022 11:22:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1668511328; bh=RUex/uVLEtUTtpMrK7R5q8A3DmJVD4YlNTI9loy8eJQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=glk47w7xi3guel3fw1pxy4K8FCcpsBMJFD8KXefzOCraQ+2YgX6DJ9Ex1PkGAc61s zSOfME613ERA8CIIToNU6uhuWgABZlEk82Si+IAZKRDUpQrg66hz3DswaUVamjG4Pa MN6yGYNOsMyW761/bRFGJfem40WlBixFR8fBNLcZmEHxnXIeFnzikS1H3YR3kEzML3 8LHktd1WmOtCjfb/v6axdRqhdcYvKXfbE2xjqpkRL7jvEP3/koBhQn+/R6IcfI78FC HOVnXDtwGmPT+00HcL0mTOklfvsDeFpP4Zne7gtgP9sikpStyPZcgACpsG1g35Us5J Uy0U4PjcPEn/Q== Received: by mail-lf1-f49.google.com with SMTP id d6so23891505lfs.10 for ; Tue, 15 Nov 2022 03:22:08 -0800 (PST) X-Gm-Message-State: ANoB5pmiiDgID0ERu82iJ2GeEE0Q7y8lb0l+Wep4XqKTeHEpsuBC48t/ P2Y3OIX8l9HHWhpsAyGomDAY+jLDMYfmOkabdKs= X-Google-Smtp-Source: AA0mqf5upU2WJXKcyknsXw7W4VQJs4KNSYC5eBDbx6d89648ofQiEYjSFn3R9Rp9WCIJ7it6fIYNJKte3XoKgsHmd+A= X-Received: by 2002:a05:6512:1042:b0:4a2:2aad:95c4 with SMTP id c2-20020a056512104200b004a22aad95c4mr6434629lfb.110.1668511326789; Tue, 15 Nov 2022 03:22:06 -0800 (PST) MIME-Version: 1.0 References: <20221108182204.2447664-1-ardb@kernel.org> <20221115111658.GA32523@willie-the-truck> In-Reply-To: <20221115111658.GA32523@willie-the-truck> From: Ard Biesheuvel Date: Tue, 15 Nov 2022 12:21:55 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v5 0/7] arm64: efi: leave MMU and caches on at boot To: Will Deacon Cc: Mark Rutland , linux-arm-kernel@lists.infradead.org, linux-efi@vger.kernel.org, keescook@chromium.org, Catalin Marinas , Marc Zyngier Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org 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. 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(). 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 E922CC433FE for ; Tue, 15 Nov 2022 11:23:13 +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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=wNgONhWt2CZs+Nal7Vz7jVADq8i5xp0mwQcNaNMOI4Q=; b=HdLCMypIkE6UQA lv+MEow9M47eyis6ead9/KWGOW3lxg84sbjTRzSrtiW0SqSdjqAvHmaC2ze8++H4uhwFF+fHvH71q 7vHZ3mhzqpsrueljNG9AOUPwI61WeXYa7/biAQLK8G/0X2juUyGtr5SNT4P2qyxRjxyRRj4gSfrIx QgBdWg7i1KatXFqy6+eTZ1BFGcsE3qBgrzeRkMZz8EGUPaaVrd1qdMeF6ehG8xMuc6hST+/OGdJXK NffalmqwWp+2gPEFHnu+cHCCIrUJqQOI+UZDGbteyhgBlXmHoUQ9I6G1mw7jIclOmwdSjboza03Co kSyP+rtn608j9qrZm0zg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ouu18-00AXld-M0; Tue, 15 Nov 2022 11:22:14 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ouu15-00AXim-Ku for linux-arm-kernel@lists.infradead.org; Tue, 15 Nov 2022 11:22:13 +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 ams.source.kernel.org (Postfix) with ESMTPS id 12486B810A0 for ; Tue, 15 Nov 2022 11:22:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C7DC7C43470 for ; Tue, 15 Nov 2022 11:22:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1668511328; bh=RUex/uVLEtUTtpMrK7R5q8A3DmJVD4YlNTI9loy8eJQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=glk47w7xi3guel3fw1pxy4K8FCcpsBMJFD8KXefzOCraQ+2YgX6DJ9Ex1PkGAc61s zSOfME613ERA8CIIToNU6uhuWgABZlEk82Si+IAZKRDUpQrg66hz3DswaUVamjG4Pa MN6yGYNOsMyW761/bRFGJfem40WlBixFR8fBNLcZmEHxnXIeFnzikS1H3YR3kEzML3 8LHktd1WmOtCjfb/v6axdRqhdcYvKXfbE2xjqpkRL7jvEP3/koBhQn+/R6IcfI78FC HOVnXDtwGmPT+00HcL0mTOklfvsDeFpP4Zne7gtgP9sikpStyPZcgACpsG1g35Us5J Uy0U4PjcPEn/Q== Received: by mail-lf1-f45.google.com with SMTP id l12so23914566lfp.6 for ; Tue, 15 Nov 2022 03:22:08 -0800 (PST) X-Gm-Message-State: ANoB5pkF3LLVIY/CVbB9B3iTeT/b8rWm9SFKTX0FJwRLV/uaBxtKIJAs B+7bWi0eaV7gQkTTIMn4dWafJK7DNmnlkyOqDA4= X-Google-Smtp-Source: AA0mqf5upU2WJXKcyknsXw7W4VQJs4KNSYC5eBDbx6d89648ofQiEYjSFn3R9Rp9WCIJ7it6fIYNJKte3XoKgsHmd+A= X-Received: by 2002:a05:6512:1042:b0:4a2:2aad:95c4 with SMTP id c2-20020a056512104200b004a22aad95c4mr6434629lfb.110.1668511326789; Tue, 15 Nov 2022 03:22:06 -0800 (PST) MIME-Version: 1.0 References: <20221108182204.2447664-1-ardb@kernel.org> <20221115111658.GA32523@willie-the-truck> In-Reply-To: <20221115111658.GA32523@willie-the-truck> From: Ard Biesheuvel Date: Tue, 15 Nov 2022 12:21:55 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v5 0/7] arm64: efi: leave MMU and caches on at boot To: Will Deacon Cc: Mark Rutland , linux-arm-kernel@lists.infradead.org, linux-efi@vger.kernel.org, keescook@chromium.org, Catalin Marinas , Marc Zyngier X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221115_032212_037159_AE5A6598 X-CRM114-Status: GOOD ( 34.27 ) 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, 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. 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(). _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel