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. 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. 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? - Felix
