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