| Message ID | 20221122170249.2453853-1-ardb@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | arm64: booting: Require placement within 48-bit addressable memory | expand |
On Tue, 22 Nov 2022 at 18:02, Ard Biesheuvel <ardb@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@kernel.org> > --- Note that this is a v2 addressing prior feedback from Mark. > Documentation/arm64/booting.rst | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst > index 8c324ad638de2b27..5a764fabfea821f0 100644 > --- a/Documentation/arm64/booting.rst > +++ b/Documentation/arm64/booting.rst > @@ -121,8 +121,9 @@ Header notes: > to the base of DRAM, since memory below it is not > accessible via the linear mapping > 1 > - 2MB aligned base may be anywhere in physical > - memory > + 2MB aligned base such that all image_size bytes > + counted from the start of the image are within > + the 48-bit addressable range of physical memory > Bits 4-63 Reserved. > ============= =============================================================== > > -- > 2.35.1 >
On Tue, Nov 22, 2022 at 06:02:49PM +0100, Ard Biesheuvel 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@kernel.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Thanks for the respin! Mark. > --- > Documentation/arm64/booting.rst | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst > index 8c324ad638de2b27..5a764fabfea821f0 100644 > --- a/Documentation/arm64/booting.rst > +++ b/Documentation/arm64/booting.rst > @@ -121,8 +121,9 @@ Header notes: > to the base of DRAM, since memory below it is not > accessible via the linear mapping > 1 > - 2MB aligned base may be anywhere in physical > - memory > + 2MB aligned base such that all image_size bytes > + counted from the start of the image are within > + the 48-bit addressable range of physical memory > Bits 4-63 Reserved. > ============= =============================================================== > > -- > 2.35.1 >
On 11/22/22 22:33, Ard Biesheuvel wrote: > On Tue, 22 Nov 2022 at 18:02, Ard Biesheuvel <ardb@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@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 ? > >> Documentation/arm64/booting.rst | 5 +++-- >> 1 file changed, 3 insertions(+), 2 deletions(-) >> >> diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst >> index 8c324ad638de2b27..5a764fabfea821f0 100644 >> --- a/Documentation/arm64/booting.rst >> +++ b/Documentation/arm64/booting.rst >> @@ -121,8 +121,9 @@ Header notes: >> to the base of DRAM, since memory below it is not >> accessible via the linear mapping >> 1 >> - 2MB aligned base may be anywhere in physical >> - memory >> + 2MB aligned base such that all image_size bytes >> + counted from the start of the image are within >> + the 48-bit addressable range of physical memory >> Bits 4-63 Reserved. >> ============= =============================================================== >> >> -- >> 2.35.1 >> > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Wed, 23 Nov 2022 at 07:30, Anshuman Khandual <anshuman.khandual@arm.com> wrote: > > > > On 11/22/22 22:33, Ard Biesheuvel wrote: > > On Tue, 22 Nov 2022 at 18:02, Ard Biesheuvel <ardb@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@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.
On 11/22/22 22:32, Ard Biesheuvel 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@kernel.org> > --- Regardless of possible vmlinux beyond 48 bits physical address discussion, this patch looks good, and complete in itself. Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> > Documentation/arm64/booting.rst | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst > index 8c324ad638de2b27..5a764fabfea821f0 100644 > --- a/Documentation/arm64/booting.rst > +++ b/Documentation/arm64/booting.rst > @@ -121,8 +121,9 @@ Header notes: > to the base of DRAM, since memory below it is not > accessible via the linear mapping > 1 > - 2MB aligned base may be anywhere in physical > - memory > + 2MB aligned base such that all image_size bytes > + counted from the start of the image are within > + the 48-bit addressable range of physical memory > Bits 4-63 Reserved. > ============= =============================================================== >
On Tue, 22 Nov 2022 18:02:49 +0100, Ard Biesheuvel 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. > > [...] Applied to arm64 (for-next/mm), thanks! [1/1] arm64: booting: Require placement within 48-bit addressable memory https://git.kernel.org/arm64/c/453dfcee70c5 Cheers,
On Fri, 25 Nov 2022 at 14:24, Will Deacon <will@kernel.org> wrote: > > On Tue, 22 Nov 2022 18:02:49 +0100, Ard Biesheuvel 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. > > > > [...] > > Applied to arm64 (for-next/mm), thanks! > > [1/1] arm64: booting: Require placement within 48-bit addressable memory > https://git.kernel.org/arm64/c/453dfcee70c5 > In the discussion with Ryan Roberts regarding my LPA2 series, it became clear that this necessarily applies to the FDT and initrd as well, given that the bootloader must not assume that the kernel can access anything residing beyond the 48-bit PA limit. Unless anyone disagrees with that, I'll prepare a follow up patch to clarify this too.
diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst index 8c324ad638de2b27..5a764fabfea821f0 100644 --- a/Documentation/arm64/booting.rst +++ b/Documentation/arm64/booting.rst @@ -121,8 +121,9 @@ Header notes: to the base of DRAM, since memory below it is not accessible via the linear mapping 1 - 2MB aligned base may be anywhere in physical - memory + 2MB aligned base such that all image_size bytes + counted from the start of the image are within + the 48-bit addressable range of physical memory Bits 4-63 Reserved. ============= ===============================================================
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@kernel.org> --- Documentation/arm64/booting.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)