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@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. 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!
