[PATCH 0/2] ARM: move FDT mapping out of linear region

[Linus Walleij]

On Tue, Oct 6, 2020 at 11:49 AM Ard Biesheuvel <ardb at kernel.org> wrote:

> For the ARM kernel, setting up the kernel's virtual address space at boot
> is tricky, given the risk of collision between 1:1 mapped regions and
> virtually remapped regions. There is also a concern regarding the exact
> mapping attributes that are needed for each region, which differs between
> ARM architecture revisions, UP vs SMP etc
>
> For this reason, the kernel VA space is set up in two stages: at early
> boot, only the kernel itself and the DT are mapped using section mappings
> and later on, all existing mappings are torn down except the one covering
> the first memblock covering the kernel, and remapped again using the full
> fledged mapping routines that can map at page granularity and use all the
> right mapping attributes.
>
> There are cases where this may result in the DT getting unmapped at
> this point, and not remapped again. For instance, if the first memblock
> is not PMD aligned, we will align it up, and mark the memory below it
> as MEMBLOCK_NOMAP, to avoid having to allocate page tables to create
> the mapping before we have a mapped memblock to allocate from. If the
> DT happens to reside in this region, it will not be mapped at all when
> the permanent kernel VA mappings are in place, resulting in crashes.
>
> As we happen to have a 4 MB hole in the kernel VA space (between the
> end of the VMALLOC space and the start of the FIXMAP region), let's
> use it to create a permanent, read-only mapping of the DT that is not
> affected by any such issues.
>
> Cc: Linus Walleij <linus.walleij at linaro.org>
> Cc: Florian Fainelli <f.fainelli at gmail.com>
> Cc: Russell King <linux at armlinux.org.uk>
> Cc: Nicolas Pitre <nico at fluxnic.net>
> Cc: Rob Herring <robh+dt at kernel.org>

Hats off, this works perfectly. I tossed these patches under my KASan
stack and it boots without any problems on the Qualcomm APQ8060
with its peculiar memory layout.

Reviewed-by/Tested-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij