[PATCH] PCI: dynamically map ECAM regions

[Russell King - ARM Linux admin]

On Thu, May 13, 2021 at 05:02:32PM +0200, Arnd Bergmann wrote:
> On Thu, May 13, 2021 at 4:18 PM Russell King <rmk+kernel at armlinux.org.uk> wrote:
> >
> > Attempting to boot 32-bit ARM kernels under QEMU's 3.x virt models
> > fails when we have more than 512M of RAM in the model as we run out
> > of vmalloc space for the PCI ECAM regions. This failure will be
> > silent when running libvirt, as the console in that situation is a
> > PCI device.
> >
> > In this configuration, the kernel maps the whole ECAM, which QEMU
> > sets up for 256 buses, even when maybe only seven buses are in use.
> > Each bus uses 1M of ECAM space, and ioremap() adds an additional
> > guard page between allocations. The kernel vmap allocator will
> > align these regions to 512K, resulting in each mapping eating 1.5M
> > of vmalloc space. This means we need 384M of vmalloc space just to
> > map all of these, which is very wasteful of resources.
> >
> > Fix this by only mapping the ECAM for buses we are going to be using.
> > In my setups, this is around seven buses in most guests, which is
> > 10.5M of vmalloc space - way smaller than the 384M that would
> > otherwise be required. This also means that the kernel can boot
> > without forcing extra RAM into highmem with the vmalloc= argument,
> > or decreasing the virtual RAM available to the guest.
> >
> > Suggested-by: Arnd Bergmann <arnd at arndb.de>
> > Signed-off-by: Russell King <rmk+kernel at armlinux.org.uk>
> 
> Looks good to me. I wonder if we should actually mark this for stable
> backports. It is a somewhat invasive change, so there is a regression
> risk, but it's also likely that others will run into this problem on distro
> kernels.

Maybe merge it first, wait a release cycle, and then request it for
stable if we think it's of benefit?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!