On Tue, Sep 9, 2025 at 11:24 PM Arnd Bergmann <[email protected]> wrote:
> - ARMv7 machines with 4GB and more exist and keep getting > kernel upgrades, but to my knowledge are not in production any > more. These are mainly 2010-2015 era chips based on rare > out-of-order cores like A15, A17 or PJ4 that were designed for > low-end servers, chromebooks and network equipment but replaced > with 64-bit chips shortly after. We had planned to bring a > CONFIG_VMSPLIT_4G_4G option to ARMv7VE to keep supporting the full > memory at a performance penalty, but currently have no plan to > finish this (volunteers welcome). I'll fill in on the details on that, because I tried, to the best of my ability to prototype this but I failed, so far. Here is what I managed to do: 1. Building on another rough prototype by Afzal Mohammed, I managed to compile the ARM32 kernel into the VMALLOC area, this works fine and here are the patches: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kernel-in-vmalloc-v6.10-rc1 This is is done so that we can unmap *most* of the kernel memory but *keep* the VMALLOC area, so that e.g. exceptions can still execute and save to stack when they occur, and we can call into the kernel to execute said exceptions. This in practice means the area 0xf1000000-0xffffffff which also includes the high exception vectors that must for natural reasons also be kept in the mapping. What we have mapped today (all of the time) is 0xc0000000-0xffffffff. A minimal 256 MB mapping from 0xf0000000-0xffffffff should be able to cover this. So when we are talking about a 4G/4G split we are talking about (4G-256MB)/(4GB-256MB) split to be exact, we would keep the bottom 256 MB. 2. On top of this I tried to decouple kernelspace and userspace allocations, in essence making anything outside vmalloc invisible to userspace by unmapping it using the fact that ARM32 (LPAE) has two separate translation table base registers: one for kernelspace and one for userspace. Step 2 makes sense because we know the reverse can work: PAN (privileged access never) makes userspace memory inaccessible from kernelspace unless explicitly requested and that works fine already, and we implemented it for LPAE with similar trickery, see commit 7af5b901e847. It's harder than it looks though and I never got it to fly, but maybe I will try again. My patches is a mess but I am a bit smarter now due to reoccurring MM-related work. Yours, Linus Walleij
