| Message ID | 20221114115810.1369005-1-ardb@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | arm64: booting: Require placement within 48-bit addressable memory | expand |
On Mon, Nov 14, 2022 at 12:58:10PM +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 repaint bit #3 in the Image header as 'must be placed within 48-bit > addressable memory', as this is the current de facto meaning, and add > bits that we may set later to allow placement outside of that. Could we just clean up the definition of bit 3 for now, then add the other bits when we actually set them? > > Signed-off-by: Ard Biesheuvel <ardb@kernel.org> > --- > Documentation/arm64/booting.rst | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst > index 8c324ad638de2b27..9919e1a107add655 100644 > --- a/Documentation/arm64/booting.rst > +++ b/Documentation/arm64/booting.rst > @@ -114,16 +114,21 @@ Header notes: > * 1 - 4K > * 2 - 16K > * 3 - 64K > - Bit 3 Kernel physical placement > + Bit 3-4 Kernel physical placement > > 0 > 2MB aligned base should be as close as possible > to the base of DRAM, since memory below it is not > accessible via the linear mapping > 1 > + 2MB aligned base such that base plus image_size is > + entirely within the 48-bit addressable range This seems to assume text_offset is zero (which is the case today, but this is the first part of booting.txt that assumes that); as a matter of policy are we sure that we'll never use a non-zero offset again? If so, we probably want to mention that in the "header notes" section, or come up with some wording to include it here. Otherwise, this looks good; I'm certainly in favour of explicitly mentioning the 48-bit restriction. Thanks, Mark. > + 2 > + Reserved > + 3 > 2MB aligned base may be anywhere in physical > memory > - Bits 4-63 Reserved. > + Bits 5-63 Reserved. > ============= =============================================================== > > - When image_size is zero, a bootloader should attempt to keep as much > -- > 2.35.1 >
On Mon, 14 Nov 2022 at 13:10, Mark Rutland <mark.rutland@arm.com> wrote: > > On Mon, Nov 14, 2022 at 12:58:10PM +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 repaint bit #3 in the Image header as 'must be placed within 48-bit > > addressable memory', as this is the current de facto meaning, and add > > bits that we may set later to allow placement outside of that. > > Could we just clean up the definition of bit 3 for now, then add the other bits > when we actually set them? > Sure > > > > Signed-off-by: Ard Biesheuvel <ardb@kernel.org> > > --- > > Documentation/arm64/booting.rst | 9 +++++++-- > > 1 file changed, 7 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst > > index 8c324ad638de2b27..9919e1a107add655 100644 > > --- a/Documentation/arm64/booting.rst > > +++ b/Documentation/arm64/booting.rst > > @@ -114,16 +114,21 @@ Header notes: > > * 1 - 4K > > * 2 - 16K > > * 3 - 64K > > - Bit 3 Kernel physical placement > > + Bit 3-4 Kernel physical placement > > > > 0 > > 2MB aligned base should be as close as possible > > to the base of DRAM, since memory below it is not > > accessible via the linear mapping > > 1 > > + 2MB aligned base such that base plus image_size is > > + entirely within the 48-bit addressable range > > This seems to assume text_offset is zero (which is the case today, but this is > the first part of booting.txt that assumes that); as a matter of policy are we > sure that we'll never use a non-zero offset again? If so, we probably want to > mention that in the "header notes" section, or come up with some wording to > include it here. > How about: 2MB aligned base such that all image_size bytes counted from the start of the image are within the 48-bit addressable range ? > Otherwise, this looks good; I'm certainly in favour of explicitly mentioning > the 48-bit restriction. > > Thanks, > Mark. >
On Mon, Nov 14, 2022 at 02:33:52PM +0100, Ard Biesheuvel wrote: > On Mon, 14 Nov 2022 at 13:10, Mark Rutland <mark.rutland@arm.com> wrote: > > > > On Mon, Nov 14, 2022 at 12:58:10PM +0100, Ard Biesheuvel wrote: > > > + Bit 3-4 Kernel physical placement > > > > > > 0 > > > 2MB aligned base should be as close as possible > > > to the base of DRAM, since memory below it is not > > > accessible via the linear mapping > > > 1 > > > + 2MB aligned base such that base plus image_size is > > > + entirely within the 48-bit addressable range > > > > This seems to assume text_offset is zero (which is the case today, but this is > > the first part of booting.txt that assumes that); as a matter of policy are we > > sure that we'll never use a non-zero offset again? If so, we probably want to > > mention that in the "header notes" section, or come up with some wording to > > include it here. > > > > How about: > > 2MB aligned base such that all image_size bytes > counted from the start of the image are within > the 48-bit addressable range > > ? Sounds good to me, thanks! Mark.
diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst index 8c324ad638de2b27..9919e1a107add655 100644 --- a/Documentation/arm64/booting.rst +++ b/Documentation/arm64/booting.rst @@ -114,16 +114,21 @@ Header notes: * 1 - 4K * 2 - 16K * 3 - 64K - Bit 3 Kernel physical placement + Bit 3-4 Kernel physical placement 0 2MB aligned base should be as close as possible to the base of DRAM, since memory below it is not accessible via the linear mapping 1 + 2MB aligned base such that base plus image_size is + entirely within the 48-bit addressable range + 2 + Reserved + 3 2MB aligned base may be anywhere in physical memory - Bits 4-63 Reserved. + Bits 5-63 Reserved. ============= =============================================================== - When image_size is zero, a bootloader should attempt to keep as much
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 repaint bit #3 in the Image header as 'must be placed within 48-bit addressable memory', as this is the current de facto meaning, and add bits that we may set later to allow placement outside of that. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> --- Documentation/arm64/booting.rst | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)