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=-6.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no 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 1F47BC433EF for ; Fri, 3 Sep 2021 17:47:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id F36A760238 for ; Fri, 3 Sep 2021 17:47:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349800AbhICRsZ (ORCPT ); Fri, 3 Sep 2021 13:48:25 -0400 Received: from mail.kernel.org ([198.145.29.99]:43896 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229789AbhICRsY (ORCPT ); Fri, 3 Sep 2021 13:48:24 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id CB5E4610F9; Fri, 3 Sep 2021 17:47:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1630691243; bh=GHPzr9KnRPIHt8M4CiAcDe/rlIXPuUPBCeZTgZ5vpIQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=c3CYMEUbv15YTiTAMOAltio0RwKJ9DpXmmhtIvrga36APhG0IAGJItdZ1cEzzosDW HqtMQZBKd2n857R7HUdbp9lnmAFDdIyDOuOSZTqvvtK3SozaG0A8EoSzYW1AshwgJk s7oUKeQtqCEy7fxTmOFfUD4t2I1Kgcut6D7WjtA6ZAyMpODKLQX7yC/IHSkdfWftle vSVC+Un7bVTgdsDfqDH0YctarxpA8THtIUF7LzKoXtcmnQBwqxzd6/GYLepexCPRpq vRNpFqg8Ma4f+0yUJ0wXOFFa5OlHQ9sJOvokuIWmJnkUxAzT1S+SxcfYia+F8z9TmU xxKnOg8TEOGuA== Received: by mail-oi1-f169.google.com with SMTP id w144so106866oie.13; Fri, 03 Sep 2021 10:47:23 -0700 (PDT) X-Gm-Message-State: AOAM5329qerYbnEpHa0mHOEH3mWxK4xyhHMAArJoDBImI2woIAo2MYGp AK0YnqqAgfrl3lTijLJPDr42v6ZxIwCLBbCbUyQ= X-Google-Smtp-Source: ABdhPJy6C2mSGLCYvOgLLumuIFftDtf2mI3ojWp06p8qQ2pdtqK0tyt/TnAtFrwSR5JrtP1FIXgulu5bxTnZi49tjwk= X-Received: by 2002:a54:418e:: with SMTP id 14mr29159oiy.174.1630691242892; Fri, 03 Sep 2021 10:47:22 -0700 (PDT) MIME-Version: 1.0 References: <20210730134552.853350-1-bert@biot.com> <20210730134552.853350-5-bert@biot.com> <7d3e2c5b-931c-1f82-77a3-fc51268f1986@nbd.name> In-Reply-To: <7d3e2c5b-931c-1f82-77a3-fc51268f1986@nbd.name> From: Ard Biesheuvel Date: Fri, 3 Sep 2021 19:47:12 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 4/5] ARM: Add basic support for EcoNet EN7523 SoC To: Felix Fietkau Cc: Arnd Bergmann , Bert Vermeulen , DTML , Linux Kernel Mailing List , Linux ARM , Russell King , Linus Walleij , Andrew Morton , Geert Uytterhoeven , Anshuman Khandual , Krzysztof Kozlowski , John Crispin , YiFei Zhu , Mike Rapoport , =?UTF-8?Q?Uwe_Kleine=2DK=C3=B6nig?= , Nick Desaulniers , Kees Cook , Masahiro Yamada , Nathan Chancellor , Viresh Kumar Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 3 Sept 2021 at 18:20, Felix Fietkau wrote: > > > On 2021-08-01 18:44, Ard Biesheuvel wrote: > > On Fri, 30 Jul 2021 at 16:48, Arnd Bergmann wrote: > >> > >> Why is this needed? > >> > >> Note also the comment directly above it exlaining > >> # Text offset. This list is sorted numerically by address in order to > >> # provide a means to avoid/resolve conflicts in multi-arch kernels. > >> > > > > Yes, please drop this - it is a horrible hack and it's already quite > > disappointing that we are stuck with it for the foreseeable future. > > > > So I assume the purpose of this is to protect the first 128k of DRAM > > to be protected from being overwritten by the decompressor? > > > > It would be best to move this reserved region elsewhere, but I can > > understand that this is no longer an option. So the alternatives are > > - omit this window from the /memory node, and rely on Geert's recent > > decompressor changes which make it discover the usable memory from the > > DT, or > > - better would be to use a /memreserve/ here (which you may already > > have?), and teach the newly added decompressor code to take those into > > account when choosing the target window for decompressing the kernel. > I looked into this issue myself and found that this approach has a > significant drawback: 2 MiB of RAM is permanently wasted for something > that only needs to be preserved during boot time. > How so? If that memory region carries your PSCI implementation, it should be preserved permanently. So at least the 512k are permanently reserved. > If the first 256 or 512 KiB of RAM are reserved in the decompressor, it > means that the first 2 MiB need to be reserved, because that's the > granularity for the kernel page mapping when the MMU is turned on. > Indeed. > If we reserve it, we also need to need to take it out of the physical > RAM address range, so there's no way to reclaim it later. > > On the other hand, with the simple textofs solution, I believe it gets > freed in a late initcall, making it usable. > > So what's the right approach to deal with this? > The right solution here is to fix your firmware/bootloader so that the PSCI reserved region is moved to the top of memory. Adding more TEXT_OFFSET hacks is really not the right approach here. 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=-4.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no 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 26B26C433EF for ; Fri, 3 Sep 2021 17:49:03 +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 E6C6160E93 for ; Fri, 3 Sep 2021 17:49:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org E6C6160E93 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: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=VWvjRJlC/y/0gwbuN3UhCylB/7dbd/hNlPUq/ipbKN0=; b=4LB6kcAKi4LOjy veFYBJv3Chn/NYoFdcSlpvquStVinkTCoSrC1XuQynwa4KMAeYPvdnshRLvZWf3xyedgkWIJxIt4t S+DhpmFw5agh834kLhPLkrNKIS/h3JEOcq7GWLA28Ovi4PyHoqZ2Vsv/Qx+qSXmF0B63QL1IOVYAA Xg7VZMCJ+HdKGmbDSNpjbfPS//x7rhI0KbZbePS1kCoAmdYadLNn5s62uE1PnMY9bCQ7AJ5WEyvY2 AykO8u6pS97CODWthxMpkwq/eHoENsUv03FRwYy5gM9Jsl5JwIz0UG6c7SvzjvzLiWaX0gB/C55mR lzW3F3lIT/j4mSlIbdag==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mMDHl-00CVD0-1y; Fri, 03 Sep 2021 17:47:29 +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 1mMDHh-00CVCE-1B for linux-arm-kernel@lists.infradead.org; Fri, 03 Sep 2021 17:47:26 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id AD0EE610E7 for ; Fri, 3 Sep 2021 17:47:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1630691243; bh=GHPzr9KnRPIHt8M4CiAcDe/rlIXPuUPBCeZTgZ5vpIQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=c3CYMEUbv15YTiTAMOAltio0RwKJ9DpXmmhtIvrga36APhG0IAGJItdZ1cEzzosDW HqtMQZBKd2n857R7HUdbp9lnmAFDdIyDOuOSZTqvvtK3SozaG0A8EoSzYW1AshwgJk s7oUKeQtqCEy7fxTmOFfUD4t2I1Kgcut6D7WjtA6ZAyMpODKLQX7yC/IHSkdfWftle vSVC+Un7bVTgdsDfqDH0YctarxpA8THtIUF7LzKoXtcmnQBwqxzd6/GYLepexCPRpq vRNpFqg8Ma4f+0yUJ0wXOFFa5OlHQ9sJOvokuIWmJnkUxAzT1S+SxcfYia+F8z9TmU xxKnOg8TEOGuA== Received: by mail-oi1-f174.google.com with SMTP id q39so110463oiw.12 for ; Fri, 03 Sep 2021 10:47:23 -0700 (PDT) X-Gm-Message-State: AOAM533GUUrEYvZ/tGHHKHTrK2dBw/o65n6JSAEcV+EWnTRaMFIAuopP rDF0/GOOJ64KVbvV4QqXOuG0mxRZ2UWbYvpTZZA= X-Google-Smtp-Source: ABdhPJy6C2mSGLCYvOgLLumuIFftDtf2mI3ojWp06p8qQ2pdtqK0tyt/TnAtFrwSR5JrtP1FIXgulu5bxTnZi49tjwk= X-Received: by 2002:a54:418e:: with SMTP id 14mr29159oiy.174.1630691242892; Fri, 03 Sep 2021 10:47:22 -0700 (PDT) MIME-Version: 1.0 References: <20210730134552.853350-1-bert@biot.com> <20210730134552.853350-5-bert@biot.com> <7d3e2c5b-931c-1f82-77a3-fc51268f1986@nbd.name> In-Reply-To: <7d3e2c5b-931c-1f82-77a3-fc51268f1986@nbd.name> From: Ard Biesheuvel Date: Fri, 3 Sep 2021 19:47:12 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 4/5] ARM: Add basic support for EcoNet EN7523 SoC To: Felix Fietkau Cc: Arnd Bergmann , Bert Vermeulen , DTML , Linux Kernel Mailing List , Linux ARM , Russell King , Linus Walleij , Andrew Morton , Geert Uytterhoeven , Anshuman Khandual , Krzysztof Kozlowski , John Crispin , YiFei Zhu , Mike Rapoport , =?UTF-8?Q?Uwe_Kleine=2DK=C3=B6nig?= , Nick Desaulniers , Kees Cook , Masahiro Yamada , Nathan Chancellor , Viresh Kumar X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210903_104725_148599_D6CFF7EF X-CRM114-Status: GOOD ( 33.52 ) 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 Fri, 3 Sept 2021 at 18:20, Felix Fietkau wrote: > > > On 2021-08-01 18:44, Ard Biesheuvel wrote: > > On Fri, 30 Jul 2021 at 16:48, Arnd Bergmann wrote: > >> > >> Why is this needed? > >> > >> Note also the comment directly above it exlaining > >> # Text offset. This list is sorted numerically by address in order to > >> # provide a means to avoid/resolve conflicts in multi-arch kernels. > >> > > > > Yes, please drop this - it is a horrible hack and it's already quite > > disappointing that we are stuck with it for the foreseeable future. > > > > So I assume the purpose of this is to protect the first 128k of DRAM > > to be protected from being overwritten by the decompressor? > > > > It would be best to move this reserved region elsewhere, but I can > > understand that this is no longer an option. So the alternatives are > > - omit this window from the /memory node, and rely on Geert's recent > > decompressor changes which make it discover the usable memory from the > > DT, or > > - better would be to use a /memreserve/ here (which you may already > > have?), and teach the newly added decompressor code to take those into > > account when choosing the target window for decompressing the kernel. > I looked into this issue myself and found that this approach has a > significant drawback: 2 MiB of RAM is permanently wasted for something > that only needs to be preserved during boot time. > How so? If that memory region carries your PSCI implementation, it should be preserved permanently. So at least the 512k are permanently reserved. > If the first 256 or 512 KiB of RAM are reserved in the decompressor, it > means that the first 2 MiB need to be reserved, because that's the > granularity for the kernel page mapping when the MMU is turned on. > Indeed. > If we reserve it, we also need to need to take it out of the physical > RAM address range, so there's no way to reclaim it later. > > On the other hand, with the simple textofs solution, I believe it gets > freed in a late initcall, making it usable. > > So what's the right approach to deal with this? > The right solution here is to fix your firmware/bootloader so that the PSCI reserved region is moved to the top of memory. Adding more TEXT_OFFSET hacks is really not the right approach here. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel