On Mon, Mar 09, 2020 at 03:59:45PM +0000, Catalin Marinas wrote: > On Sun, Mar 08, 2020 at 11:58:52AM +0100, Arnd Bergmann wrote: > > - revisit CONFIG_VMSPLIT_4G_4G for arm32 (and maybe mips32) > > to see if it can be done, and what the overhead is. This is probably > > more work than the others combined, but also the most promising > > as it allows the most user address space and physical ram to be used. > > A rough outline of such support (and likely to miss some corner cases): > > 1. Kernel runs with its own ASID and non-global page tables. > > 2. Trampoline code on exception entry/exit to handle the TTBR0 switching > between user and kernel. > > 3. uaccess routines need to be reworked to pin the user pages in memory > (get_user_pages()) and access them via the kernel address space. > > Point 3 is probably the ugliest and it would introduce a noticeable > slowdown in certain syscalls. We also need to consider that it has implications for the single-kernel support; a kernel doing this kind of switching would likely be horrid for a kernel supporting v6+ with VIPT aliasing caches. Would we be adding a new red line between kernels supporting VIPT-aliasing caches (present in earlier v6 implementations) and kernels using this system? -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up
