On Thu, May 13, 2021 at 05:02:32PM +0200, Arnd Bergmann wrote:

On Thu, May 13, 2021 at 4:18 PM Russell King [off-list ref] wrote:

quoted

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@arndb.de>
Signed-off-by: Russell King <redacted>

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!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel