[PATCH v6 04/41] arm64: mm: Move PCI I/O emulation region above the vmemmap region

[Mark Rutland]

On Mon, Dec 11, 2023 at 03:10:00PM +0100, Ard Biesheuvel wrote:
> On Mon, 11 Dec 2023 at 14:57, Mark Rutland <mark.rutland at arm.com> wrote:
> >
> > Hi Ard,
> >
> > On Wed, Nov 29, 2023 at 12:16:00PM +0100, Ard Biesheuvel wrote:
> > > From: Ard Biesheuvel <ardb at kernel.org>
> > >
> > > Move the PCI I/O region above the vmemmap region in the kernel's VA
> > > space. This will permit us to reclaim the lower part of the vmemmap
> > > region for vmalloc/vmap allocations when running a 52-bit VA capable
> > > build on a 48-bit VA capable system.
> > >
> > > Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
> > > ---
> > >  arch/arm64/include/asm/memory.h | 4 ++--
> > >  arch/arm64/mm/ptdump.c          | 4 ++--
> > >  2 files changed, 4 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> > > index b8d726f951ae..99caeff78e1a 100644
> > > --- a/arch/arm64/include/asm/memory.h
> > > +++ b/arch/arm64/include/asm/memory.h
> > > @@ -49,8 +49,8 @@
> > >  #define MODULES_VSIZE                (SZ_2G)
> > >  #define VMEMMAP_START                (-(UL(1) << (VA_BITS - VMEMMAP_SHIFT)))
> > >  #define VMEMMAP_END          (VMEMMAP_START + VMEMMAP_SIZE)
> > > -#define PCI_IO_END           (VMEMMAP_START - SZ_8M)
> > > -#define PCI_IO_START         (PCI_IO_END - PCI_IO_SIZE)
> > > +#define PCI_IO_START         (VMEMMAP_END + SZ_8M)
> > > +#define PCI_IO_END           (PCI_IO_START + PCI_IO_SIZE)
> > >  #define FIXADDR_TOP          (VMEMMAP_START - SZ_32M)
> >
> > This looks simple, but it does have a subtle dependency on VMEMMAP_SIZE being
> > sufficiently smaller than the negative offset we choose for VMEMMAP_START, and
> > it took mw a while to convince myself that we always ensure that today. I could
> > well imagine that we try to reduce that in future (given for most
> > configurations we're reserving around double the space we actually need), and
> > it would be nice if we could avoid that going wrong.
> >
> 
> Yes, we are relying on the fact that the upper region is not covered
> by struct pages, so there is guaranteed to be an unused region at the
> very top.

Yep; exactly. My fear is that in future someone realises that:

	(-(UL(1) << (VA_BITS - VMEMMAP_SHIFT)))

... is actually reserving ~2x the space it needs for *most* configurations (since for 
most configurations we only need the VMEMMAP to account for (VA_BITS-1) bits of
linear map). If they try to shrink the VMEMMAP region in for those cases, it's
liable to overlap subsequent regions and/or to wrap those past the end of the
VA space.

> One of the constants in the equation that describes the size of this
> unused region is the size of a struct page, and so I agree this needs
> a couple of static asserts to ensure we don't get inadvertent
> overlaps.

That'd be great, thanks!

Mark.