On Thu, May 13, 2021 at 4:18 PM Russell King <rmk+kernel@xxxxxxxxxxxxxxx> 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@xxxxxxxx> > Signed-off-by: Russell King <rmk+kernel@xxxxxxxxxxxxxxx> 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. Reviewed-by: Arnd Bergmann <arnd@xxxxxxxx>
