[PATCH] arm64: booting: Require placement within 48-bit addressable memory

[Ard Biesheuvel]

On Wed, 23 Nov 2022 at 07:30, Anshuman Khandual
<anshuman.khandual at arm.com> wrote:
>
>
>
> On 11/22/22 22:33, Ard Biesheuvel wrote:
> > On Tue, 22 Nov 2022 at 18:02, Ard Biesheuvel <ardb at kernel.org> wrote:
> >>
> >> Some configurations (i.e., 64k + LVA/LPA) can tolerate a physical
> >> placement of the kernel image outside of the 48-bit addressable region,
> >> but given that the loader has no way of knowing whether or not the image
> >> in question supports LVA/LPA, it currently has no choice but to place it
> >> below the 48-bit mark.
> >>
> >> Once we add support for LPA2, which allows 52-bit physical and virtual
> >> addressing when using 4k or 16k pages, but in way that relies on
> >> increasing the number of paging levels, there will be more variety in
> >> the configurations that may or may not support this.
> >>
> >> So redefine bit #3 in the Image header as 'must be placed within 48-bit
> >> addressable memory', as this is the current de facto meaning.
> >>
> >> Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
> >> ---
> >
> > Note that this is a v2 addressing prior feedback from Mark.
>
> As you had mentioned earlier, currently [64K|52VA|52PA] can boot the vmlinux
> loaded beyond 48 bits PA. Why should not the kernel header flags be extended
> right away to support mentioned FEAT_LPA config and also let the kernel write
> update these extended flags when applicable. Why wait for FEAT_LPA2 ?
>

I am not suggesting to wait for FEAT_LPA2.

I am suggesting to only support kernels loaded into 48 bit addressable
physical memory. There is simply no point, as no system is likely to
ever exist that relies on this, so this will be dead code that only
ever gets tested if someone bothers to run it on a doctored emulator
that has all its memory outside of that region.

By the same reasoning, there is really no point in updating the ID map
extension code to account for this: that feature was specifically
intended for being able to boot AMD seattle with a 39-bit VA 4k pages
kernel at a time when the only alternative we had was 42-bit 64k
pages. Also, given that LPA2 is defined as a single feature that
covers both virtual and physical addressing up to 52 bits, and that
the virtual addressing part requires the physical addressing part, I
don't see a point in supporting 52-bit physical addressing without
52-bit virtual addressing, which means the ID map extension case
simply ceases to exist for LPA2.