Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210730134552.853350-1-bert@biot.com> <20210730134552.853350-5-bert@biot.com>
 <CAK8P3a3OuJ3pMSdEA4Rt3aWvvuX2+_Bg5x7-kZ1++fvvJvgGxA@mail.gmail.com>
 <CAMj1kXFK+HoouMMBbHxEgm-zQqKa6QMS6keeZmhpXTc4FCy8fQ@mail.gmail.com> <7d3e2c5b-931c-1f82-77a3-fc51268f1986@nbd.name>
In-Reply-To: <7d3e2c5b-931c-1f82-77a3-fc51268f1986@nbd.name>
From:   Ard Biesheuvel <ardb@kernel.org>
Date:   Fri, 3 Sep 2021 19:47:12 +0200
Message-ID: <CAMj1kXHGfTSv+95NJF1BPS76M6-6FF9GQk24L2LLG9Epx4FpfA@mail.gmail.com>
Subject: Re: [PATCH 4/5] ARM: Add basic support for EcoNet EN7523 SoC
To:     Felix Fietkau <nbd@nbd.name>
Cc:     Arnd Bergmann <arnd@arndb.de>, Bert Vermeulen <bert@biot.com>,
        DTML <devicetree@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux ARM <linux-arm-kernel@lists.infradead.org>,
        Russell King <linux@armlinux.org.uk>,
        Linus Walleij <linus.walleij@linaro.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Geert Uytterhoeven <geert+renesas@glider.be>,
        Anshuman Khandual <anshuman.khandual@arm.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>,
        John Crispin <john@phrozen.org>,
        YiFei Zhu <yifeifz2@illinois.edu>,
        Mike Rapoport <rppt@kernel.org>,
        =?UTF-8?Q?Uwe_Kleine=2DK=C3=B6nig?= 
        <u.kleine-koenig@pengutronix.de>,
        Nick Desaulniers <ndesaulniers@google.com>,
        Kees Cook <keescook@chromium.org>,
        Masahiro Yamada <masahiroy@kernel.org>,
        Nathan Chancellor <nathan@kernel.org>,
        Viresh Kumar <viresh.kumar@linaro.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, 3 Sept 2021 at 18:20, Felix Fietkau <nbd@nbd.name> wrote:
>
>
> On 2021-08-01 18:44, Ard Biesheuvel wrote:
> > On Fri, 30 Jul 2021 at 16:48, Arnd Bergmann <arnd@arndb.de> 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.