| Message ID | 20230307140522.2311461-10-ardb@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | arm64: Add support for LPA2 at stage1 and WXN | expand |
On 07/03/2023 14:04, Ard Biesheuvel wrote: > The vmemmap array is statically sized based on the maximum supported > size of the virtual address space, but it is located inside the upper VA > region, which is statically sized based on the *minimum* supported size > of the VA space. This doesn't matter much when using 64k pages, which is > the only configuration that currently supports 52-bit virtual > addressing. As I understand it, the vmemmap section only holds struct pages, and the number of struct pages in the system is surely a function of PA size, not VA size? So why is the region sized based on VA size? > > However, upcoming LPA2 support will change this picture somewhat, as in > that case, the vmemmap array will take up more than 25% of the upper VA > region when using 4k pages. Given that most of this space is never used > when running on a system that does not support 52-bit virtual > addressing, let's reclaim the unused vmemmap area in that case. > > Signed-off-by: Ard Biesheuvel <ardb@kernel.org> > --- > arch/arm64/include/asm/pgtable.h | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h > index 3eff06c5d0eb73c7..2259898e8c3d990a 100644 > --- a/arch/arm64/include/asm/pgtable.h > +++ b/arch/arm64/include/asm/pgtable.h > @@ -18,11 +18,15 @@ > * VMALLOC range. > * > * VMALLOC_START: beginning of the kernel vmalloc space > - * VMALLOC_END: extends to the available space below vmemmap, PCI I/O space > - * and fixed mappings > + * VMALLOC_END: extends to the available space below vmemmap > */ > #define VMALLOC_START (MODULES_END) > +#if VA_BITS == VA_BITS_MIN > #define VMALLOC_END (VMEMMAP_START - SZ_8M) > +#else > +#define VMEMMAP_UNUSED_NPAGES ((_PAGE_OFFSET(vabits_actual) - PAGE_OFFSET) >> PAGE_SHIFT) > +#define VMALLOC_END (VMEMMAP_START + VMEMMAP_UNUSED_NPAGES * sizeof(struct page) - SZ_8M) > +#endif > > #define vmemmap ((struct page *)VMEMMAP_START - (memstart_addr >> PAGE_SHIFT)) >
On Tue, 7 Mar 2023 at 17:42, Ryan Roberts <ryan.roberts@arm.com> wrote: > > On 07/03/2023 14:04, Ard Biesheuvel wrote: > > The vmemmap array is statically sized based on the maximum supported > > size of the virtual address space, but it is located inside the upper VA > > region, which is statically sized based on the *minimum* supported size > > of the VA space. This doesn't matter much when using 64k pages, which is > > the only configuration that currently supports 52-bit virtual > > addressing. > > As I understand it, the vmemmap section only holds struct pages, and the number > of struct pages in the system is surely a function of PA size, not VA size? So > why is the region sized based on VA size? > We do not implement CONFIG_HIGHMEM on arm64, and so the addressable PA range is bounded by the size of the linear map (and in some cases, DRAM starts outside of the VA addressable range entirely, e.g., on AMD Seattle with 38-bit VAs). Also, the start of the linear map (i.e., PAGE_OFFSET) does not correspond with PA 0x0, it is based on the physical placement of system memory, and it is randomized in some cases as well. This is why we have #define vmemmap ((struct page *)VMEMMAP_START - (memstart_addr >> PAGE_SHIFT)) This means btw that we could reclaim even more vmemmap space, i.e., nothing below phys_to_page(memblock_start_of_DRAM()) will ever be used, but there are some intricacies with section rounding etc which make this a bit tricky. The main reason for this patch is to free up 15/16 of the vmemmap region when using LPA2 and 4k pages, so that the resulting VA space layout is identical to 48-bits/4k pages, making LPA2 support enabled a reasonable default. > > > > However, upcoming LPA2 support will change this picture somewhat, as in > > that case, the vmemmap array will take up more than 25% of the upper VA > > region when using 4k pages. Given that most of this space is never used > > when running on a system that does not support 52-bit virtual > > addressing, let's reclaim the unused vmemmap area in that case. > > > > Signed-off-by: Ard Biesheuvel <ardb@kernel.org> > > --- > > arch/arm64/include/asm/pgtable.h | 8 ++++++-- > > 1 file changed, 6 insertions(+), 2 deletions(-) > > > > diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h > > index 3eff06c5d0eb73c7..2259898e8c3d990a 100644 > > --- a/arch/arm64/include/asm/pgtable.h > > +++ b/arch/arm64/include/asm/pgtable.h > > @@ -18,11 +18,15 @@ > > * VMALLOC range. > > * > > * VMALLOC_START: beginning of the kernel vmalloc space > > - * VMALLOC_END: extends to the available space below vmemmap, PCI I/O space > > - * and fixed mappings > > + * VMALLOC_END: extends to the available space below vmemmap > > */ > > #define VMALLOC_START (MODULES_END) > > +#if VA_BITS == VA_BITS_MIN > > #define VMALLOC_END (VMEMMAP_START - SZ_8M) > > +#else > > +#define VMEMMAP_UNUSED_NPAGES ((_PAGE_OFFSET(vabits_actual) - PAGE_OFFSET) >> PAGE_SHIFT) > > +#define VMALLOC_END (VMEMMAP_START + VMEMMAP_UNUSED_NPAGES * sizeof(struct page) - SZ_8M) > > +#endif > > > > #define vmemmap ((struct page *)VMEMMAP_START - (memstart_addr >> PAGE_SHIFT)) > > >
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h index 3eff06c5d0eb73c7..2259898e8c3d990a 100644 --- a/arch/arm64/include/asm/pgtable.h +++ b/arch/arm64/include/asm/pgtable.h @@ -18,11 +18,15 @@ * VMALLOC range. * * VMALLOC_START: beginning of the kernel vmalloc space - * VMALLOC_END: extends to the available space below vmemmap, PCI I/O space - * and fixed mappings + * VMALLOC_END: extends to the available space below vmemmap */ #define VMALLOC_START (MODULES_END) +#if VA_BITS == VA_BITS_MIN #define VMALLOC_END (VMEMMAP_START - SZ_8M) +#else +#define VMEMMAP_UNUSED_NPAGES ((_PAGE_OFFSET(vabits_actual) - PAGE_OFFSET) >> PAGE_SHIFT) +#define VMALLOC_END (VMEMMAP_START + VMEMMAP_UNUSED_NPAGES * sizeof(struct page) - SZ_8M) +#endif #define vmemmap ((struct page *)VMEMMAP_START - (memstart_addr >> PAGE_SHIFT))
The vmemmap array is statically sized based on the maximum supported size of the virtual address space, but it is located inside the upper VA region, which is statically sized based on the *minimum* supported size of the VA space. This doesn't matter much when using 64k pages, which is the only configuration that currently supports 52-bit virtual addressing. However, upcoming LPA2 support will change this picture somewhat, as in that case, the vmemmap array will take up more than 25% of the upper VA region when using 4k pages. Given that most of this space is never used when running on a system that does not support 52-bit virtual addressing, let's reclaim the unused vmemmap area in that case. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> --- arch/arm64/include/asm/pgtable.h | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)