| Message ID | 20190807155524.5112-1-steve.capper@arm.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | 52-bit kernel + user VAs | expand |
On Wed, Aug 07, 2019 at 04:55:12PM +0100, Steve Capper wrote: > This patch series adds support for 52-bit kernel VAs using some of the > machinery already introduced by the 52-bit userspace VA code in 5.0. Cheers, I've pushed this out on a for-next/52-bit-kva branch with one small patch on top and Catalin's tags added. Will
On Fri, Aug 09, 2019 at 05:47:17PM +0100, Will Deacon wrote: > On Wed, Aug 07, 2019 at 04:55:12PM +0100, Steve Capper wrote: > > This patch series adds support for 52-bit kernel VAs using some of the > > machinery already introduced by the 52-bit userspace VA code in 5.0. > > Cheers, I've pushed this out on a for-next/52-bit-kva branch with one > small patch on top and Catalin's tags added. > Many thanks Will! Cheers,
On Tue, Aug 13, 2019 at 11:23:50AM +0000, Steve Capper wrote: > On Fri, Aug 09, 2019 at 05:47:17PM +0100, Will Deacon wrote: > > On Wed, Aug 07, 2019 at 04:55:12PM +0100, Steve Capper wrote: > > > This patch series adds support for 52-bit kernel VAs using some of the > > > machinery already introduced by the 52-bit userspace VA code in 5.0. > > > > Cheers, I've pushed this out on a for-next/52-bit-kva branch with one > > small patch on top and Catalin's tags added. > > > > Many thanks Will! Save your thanks for when I've fixed the bugs ;) Will
Hi Will, Steve, On Fri, Aug 9, 2019 at 6:47 PM Will Deacon <will@kernel.org> wrote: > On Wed, Aug 07, 2019 at 04:55:12PM +0100, Steve Capper wrote: > > This patch series adds support for 52-bit kernel VAs using some of the > > machinery already introduced by the 52-bit userspace VA code in 5.0. > > Cheers, I've pushed this out on a for-next/52-bit-kva branch with one > small patch on top and Catalin's tags added. As of commit 14c127c957c1c607 ("arm64: mm: Flip kernel VA space"), the kernel log is spammed with virt_to_phys used for non-linear address: (____ptrval____) (__func__.6603+0x14d681/0x17fb3d) WARNING: CPU: 0 PID: 264 at arch/arm64/mm/physaddr.c:15 __virt_to_phys+0x28/0x58 Modules linked in: CPU: 0 PID: 264 Comm: mdev Not tainted 5.3.0-rc3-rcar3-initrd-00002-g14c127c957c1c607 #38 Hardware name: Renesas Ebisu-4D board based on r8a77990 (DT) pstate: 60000005 (nZCv daif -PAN -UAO) pc : __virt_to_phys+0x28/0x58 lr : __virt_to_phys+0x28/0x58 sp : ffffffc011953c80 x29: ffffffc011953c80 x28: ffffff8078790140 x27: 0000000000000000 x26: 0000000000000000 x25: ffffffc010a539b9 x24: ffffffc010a86000 x23: ffffffc010a539ba x22: 0000000000000001 x21: 0000000000202038 x20: 0000000000000001 x19: ffffffc010a539b9 x18: 000000000000000a x17: 0000000000000000 x16: 0000000000000000 x15: 00000000000ca51d x14: 0720072007200720 x13: 0720072007200720 x12: 0720072007200720 x11: 0720072007200720 x10: 0720072007200720 x9 : 0720072007200720 x8 : 0000000000000001 x7 : 0000000000000007 x6 : ffffff8079824f00 x5 : 0000000000000140 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 00000000ffffffff x1 : 0713abbc9281cf00 x0 : 0000000000000000 Call trace: __virt_to_phys+0x28/0x58 __check_object_size+0xd0/0x1e0 filldir64+0x1d8/0x2b0 kernfs_fop_readdir+0x64/0x200 iterate_dir+0x68/0x144 ksys_getdents64+0x88/0x154 __arm64_sys_getdents64+0x18/0x24 el0_svc_common.constprop.0+0x84/0xe8 el0_svc_compat_handler+0x18/0x20 el0_svc_compat+0x8/0x10 ---[ end trace 6980a45f636e18be ]--- as soon as userspace starts. As this commit cannot be reverted easily, I had to revert the full branch with "git revert -m 1 6ce0dc725177e9856c9a67f2e2cabb3f7a3d90d7". Gr{oetje,eeting}s, Geert
Hi Geert, On Tue, Aug 13, 2019 at 02:43:23PM +0200, Geert Uytterhoeven wrote: > On Fri, Aug 9, 2019 at 6:47 PM Will Deacon <will@kernel.org> wrote: > > On Wed, Aug 07, 2019 at 04:55:12PM +0100, Steve Capper wrote: > > > This patch series adds support for 52-bit kernel VAs using some of the > > > machinery already introduced by the 52-bit userspace VA code in 5.0. > > > > Cheers, I've pushed this out on a for-next/52-bit-kva branch with one > > small patch on top and Catalin's tags added. > > As of commit 14c127c957c1c607 ("arm64: mm: Flip kernel VA space"), the > kernel log is spammed with > > virt_to_phys used for non-linear address: (____ptrval____) > (__func__.6603+0x14d681/0x17fb3d) > WARNING: CPU: 0 PID: 264 at arch/arm64/mm/physaddr.c:15 > __virt_to_phys+0x28/0x58 > Modules linked in: > CPU: 0 PID: 264 Comm: mdev Not tainted > 5.3.0-rc3-rcar3-initrd-00002-g14c127c957c1c607 #38 > Hardware name: Renesas Ebisu-4D board based on r8a77990 (DT) > pstate: 60000005 (nZCv daif -PAN -UAO) > pc : __virt_to_phys+0x28/0x58 > lr : __virt_to_phys+0x28/0x58 > sp : ffffffc011953c80 > x29: ffffffc011953c80 x28: ffffff8078790140 > x27: 0000000000000000 x26: 0000000000000000 > x25: ffffffc010a539b9 x24: ffffffc010a86000 > x23: ffffffc010a539ba x22: 0000000000000001 > x21: 0000000000202038 x20: 0000000000000001 > x19: ffffffc010a539b9 x18: 000000000000000a > x17: 0000000000000000 x16: 0000000000000000 > x15: 00000000000ca51d x14: 0720072007200720 > x13: 0720072007200720 x12: 0720072007200720 > x11: 0720072007200720 x10: 0720072007200720 > x9 : 0720072007200720 x8 : 0000000000000001 > x7 : 0000000000000007 x6 : ffffff8079824f00 > x5 : 0000000000000140 x4 : 0000000000000000 > x3 : 0000000000000000 x2 : 00000000ffffffff > x1 : 0713abbc9281cf00 x0 : 0000000000000000 > Call trace: > __virt_to_phys+0x28/0x58 > __check_object_size+0xd0/0x1e0 > filldir64+0x1d8/0x2b0 > kernfs_fop_readdir+0x64/0x200 > iterate_dir+0x68/0x144 > ksys_getdents64+0x88/0x154 > __arm64_sys_getdents64+0x18/0x24 > el0_svc_common.constprop.0+0x84/0xe8 > el0_svc_compat_handler+0x18/0x20 > el0_svc_compat+0x8/0x10 > ---[ end trace 6980a45f636e18be ]--- > > as soon as userspace starts. Can you try the hack I posted here, please? https://lkml.org/lkml/2019/8/13/555 Also, what .config are you using? Will
Hi Will, On Tue, Aug 13, 2019 at 3:10 PM Will Deacon <will@kernel.org> wrote: > On Tue, Aug 13, 2019 at 02:43:23PM +0200, Geert Uytterhoeven wrote: > > On Fri, Aug 9, 2019 at 6:47 PM Will Deacon <will@kernel.org> wrote: > > > On Wed, Aug 07, 2019 at 04:55:12PM +0100, Steve Capper wrote: > > > > This patch series adds support for 52-bit kernel VAs using some of the > > > > machinery already introduced by the 52-bit userspace VA code in 5.0. > > > > > > Cheers, I've pushed this out on a for-next/52-bit-kva branch with one > > > small patch on top and Catalin's tags added. > > > > As of commit 14c127c957c1c607 ("arm64: mm: Flip kernel VA space"), the > > kernel log is spammed with > > > > virt_to_phys used for non-linear address: (____ptrval____) > > (__func__.6603+0x14d681/0x17fb3d) > > WARNING: CPU: 0 PID: 264 at arch/arm64/mm/physaddr.c:15 > > __virt_to_phys+0x28/0x58 > > Modules linked in: > > CPU: 0 PID: 264 Comm: mdev Not tainted > > 5.3.0-rc3-rcar3-initrd-00002-g14c127c957c1c607 #38 > > Hardware name: Renesas Ebisu-4D board based on r8a77990 (DT) > > pstate: 60000005 (nZCv daif -PAN -UAO) > > pc : __virt_to_phys+0x28/0x58 > > lr : __virt_to_phys+0x28/0x58 > > sp : ffffffc011953c80 > > x29: ffffffc011953c80 x28: ffffff8078790140 > > x27: 0000000000000000 x26: 0000000000000000 > > x25: ffffffc010a539b9 x24: ffffffc010a86000 > > x23: ffffffc010a539ba x22: 0000000000000001 > > x21: 0000000000202038 x20: 0000000000000001 > > x19: ffffffc010a539b9 x18: 000000000000000a > > x17: 0000000000000000 x16: 0000000000000000 > > x15: 00000000000ca51d x14: 0720072007200720 > > x13: 0720072007200720 x12: 0720072007200720 > > x11: 0720072007200720 x10: 0720072007200720 > > x9 : 0720072007200720 x8 : 0000000000000001 > > x7 : 0000000000000007 x6 : ffffff8079824f00 > > x5 : 0000000000000140 x4 : 0000000000000000 > > x3 : 0000000000000000 x2 : 00000000ffffffff > > x1 : 0713abbc9281cf00 x0 : 0000000000000000 > > Call trace: > > __virt_to_phys+0x28/0x58 > > __check_object_size+0xd0/0x1e0 > > filldir64+0x1d8/0x2b0 > > kernfs_fop_readdir+0x64/0x200 > > iterate_dir+0x68/0x144 > > ksys_getdents64+0x88/0x154 > > __arm64_sys_getdents64+0x18/0x24 > > el0_svc_common.constprop.0+0x84/0xe8 > > el0_svc_compat_handler+0x18/0x20 > > el0_svc_compat+0x8/0x10 > > ---[ end trace 6980a45f636e18be ]--- > > > > as soon as userspace starts. > > Can you try the hack I posted here, please? > > https://lkml.org/lkml/2019/8/13/555 Thanks, that seems to do the trick! Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> > Also, what .config are you using? Attached. Probably CONFIG_DEBUG_VIRTUAL=y is what you're missing. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Hi Will, Steve, I still see the following issue on a 48-bit hardware (i.e. _non_ ARMv8.2 hardware) with branch 'for-next/52-bit-kva' with commit d2d73d2fef421ca0d4 as the HEAD: [ 41.318745] Freeing initrd memory: 25856K [ 41.333312] hw perfevents: enabled with armv8_pmuv3_0 PMU driver, 7 counters available [ 41.341818] kvm [1]: IPA Size Limit: 44bits [ 41.346131] kvm [1]: GICv3: no GICV resource entry [ 41.350908] kvm [1]: disabling GICv2 emulation [ 41.355358] kvm [1]: GIC system register CPU interface enabled [ 41.363504] kvm [1]: vgic interrupt IRQ1 [ 41.370029] kvm [1]: VHE mode initialized successfully [ 41.380484] Unable to handle kernel paging request at virtual address ffffffffffe432c8 [ 41.388401] Mem abort info: [ 41.391182] ESR = 0x96000006 [ 41.394227] Exception class = DABT (current EL), IL = 32 bits [ 41.400133] SET = 0, FnV = 0 [ 41.403176] EA = 0, S1PTW = 0 [ 41.406303] Data abort info: [ 41.409170] ISV = 0, ISS = 0x00000006 [ 41.412994] CM = 0, WnR = 0 [ 41.415949] swapper pgtable: 64k pages, 48-bit VAs, pgdp=0000000081230000 [ 41.422726] [ffffffffffe432c8] pgd=0000000081890003, pud=0000000081890003, pmd=0000000000000000 [ 41.431413] Internal error: Oops: 96000006 [#1] SMP [ 41.436278] Modules linked in: [ 41.439321] CPU: 2 PID: 1357 Comm: modprobe Not tainted 5.3.0-rc3+ #1 [ 41.445748] Hardware name: To be filled by O.E.M. Saber/Saber, BIOS 0ACKL025 01/18/2019 [ 41.453738] pstate: 80400009 (Nzcv daif +PAN -UAO) [ 41.458520] pc : __check_object_size+0xc8/0x1f8 [ 41.463037] lr : __check_object_size+0xac/0x1f8 [ 41.467553] sp : ffff800031b2fcf0 [ 41.470854] x29: ffff800031b2fcf0 x28: ffff009f51c1c440 [ 41.476153] x27: 0000000000000000 x26: 0000000000002d29 [ 41.481451] x25: ffff009f51c1c440 x24: 0000000000000018 [ 41.486749] x23: 0000000000000004 x22: ffff800010cb1a19 [ 41.492046] x21: 0000000000000001 x20: 0000000000000001 [ 41.497344] x19: ffff800010cb1a18 x18: 0000000000000000 [ 41.502641] x17: 0000000000000000 x16: 0000000000000000 [ 41.507939] x15: 0000000000000000 x14: 0000000000000000 [ 41.513236] x13: 0000000000000000 x12: 0000000000000000 [ 41.518533] x11: 0000000000000000 x10: 0000000000000000 [ 41.523831] x9 : 0000000000000000 x8 : 0000000000000000 [ 41.529129] x7 : 000000003fcf0000 x6 : 0000000000000018 [ 41.534426] x5 : ffff800011d22840 x4 : ffff800011d22828 [ 41.539723] x3 : 0000000000000002 x2 : ffffffffffe432c0 [ 41.545021] x1 : 00000000c0000000 x0 : ffffffdfffe00000 [ 41.550319] Call trace: [ 41.552753] __check_object_size+0xc8/0x1f8 [ 41.556923] filldir64+0x1e0/0x2d8 [ 41.560312] dcache_readdir+0x60/0x180 [ 41.564048] iterate_dir+0x14c/0x1a0 [ 41.567609] ksys_getdents64+0xa0/0x170 [ 41.571431] __arm64_sys_getdents64+0x28/0x38 [ 41.575777] el0_svc_handler+0xb0/0x180 [ 41.579601] el0_svc+0x8/0xc [ 41.582472] Code: b26babe0 d350fc42 f2dffbe0 8b021802 (f9400440) [ 41.588639] ---[ end trace 1e1de241f266e888 ]--- [ 41.593243] Kernel panic - not syncing: Fatal exception [ 41.598477] SMP: stopping secondary CPUs [ 41.602431] Kernel Offset: disabled [ 41.605907] CPU features: 0x0002,22000c38 [ 41.609902] Memory Limit: none [ 41.612967] ---[ end Kernel panic - not syncing: Fatal exception ]--- - git bisect points to 14c127c957c1c6070 as the offending patch. - Here is a brief snippet of my .config flags enabling 48-bit VA and 52-bit PA: CONFIG_ARM64_64K_PAGES=y CONFIG_ARM64_VA_BITS_48=y CONFIG_ARM64_VA_BITS=48 CONFIG_ARM64_PA_BITS_52=y CONFIG_ARM64_PA_BITS=52 - Any idea if this is the same issue as Geert observed? Or should I debug it further to determine the offending code in the patch pointed to by git bisect. Thanks, Bhupesh On Tue, Aug 13, 2019 at 7:06 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Will, > > On Tue, Aug 13, 2019 at 3:10 PM Will Deacon <will@kernel.org> wrote: > > On Tue, Aug 13, 2019 at 02:43:23PM +0200, Geert Uytterhoeven wrote: > > > On Fri, Aug 9, 2019 at 6:47 PM Will Deacon <will@kernel.org> wrote: > > > > On Wed, Aug 07, 2019 at 04:55:12PM +0100, Steve Capper wrote: > > > > > This patch series adds support for 52-bit kernel VAs using some of the > > > > > machinery already introduced by the 52-bit userspace VA code in 5.0. > > > > > > > > Cheers, I've pushed this out on a for-next/52-bit-kva branch with one > > > > small patch on top and Catalin's tags added. > > > > > > As of commit 14c127c957c1c607 ("arm64: mm: Flip kernel VA space"), the > > > kernel log is spammed with > > > > > > virt_to_phys used for non-linear address: (____ptrval____) > > > (__func__.6603+0x14d681/0x17fb3d) > > > WARNING: CPU: 0 PID: 264 at arch/arm64/mm/physaddr.c:15 > > > __virt_to_phys+0x28/0x58 > > > Modules linked in: > > > CPU: 0 PID: 264 Comm: mdev Not tainted > > > 5.3.0-rc3-rcar3-initrd-00002-g14c127c957c1c607 #38 > > > Hardware name: Renesas Ebisu-4D board based on r8a77990 (DT) > > > pstate: 60000005 (nZCv daif -PAN -UAO) > > > pc : __virt_to_phys+0x28/0x58 > > > lr : __virt_to_phys+0x28/0x58 > > > sp : ffffffc011953c80 > > > x29: ffffffc011953c80 x28: ffffff8078790140 > > > x27: 0000000000000000 x26: 0000000000000000 > > > x25: ffffffc010a539b9 x24: ffffffc010a86000 > > > x23: ffffffc010a539ba x22: 0000000000000001 > > > x21: 0000000000202038 x20: 0000000000000001 > > > x19: ffffffc010a539b9 x18: 000000000000000a > > > x17: 0000000000000000 x16: 0000000000000000 > > > x15: 00000000000ca51d x14: 0720072007200720 > > > x13: 0720072007200720 x12: 0720072007200720 > > > x11: 0720072007200720 x10: 0720072007200720 > > > x9 : 0720072007200720 x8 : 0000000000000001 > > > x7 : 0000000000000007 x6 : ffffff8079824f00 > > > x5 : 0000000000000140 x4 : 0000000000000000 > > > x3 : 0000000000000000 x2 : 00000000ffffffff > > > x1 : 0713abbc9281cf00 x0 : 0000000000000000 > > > Call trace: > > > __virt_to_phys+0x28/0x58 > > > __check_object_size+0xd0/0x1e0 > > > filldir64+0x1d8/0x2b0 > > > kernfs_fop_readdir+0x64/0x200 > > > iterate_dir+0x68/0x144 > > > ksys_getdents64+0x88/0x154 > > > __arm64_sys_getdents64+0x18/0x24 > > > el0_svc_common.constprop.0+0x84/0xe8 > > > el0_svc_compat_handler+0x18/0x20 > > > el0_svc_compat+0x8/0x10 > > > ---[ end trace 6980a45f636e18be ]--- > > > > > > as soon as userspace starts. > > > > Can you try the hack I posted here, please? > > > > https://lkml.org/lkml/2019/8/13/555 > > Thanks, that seems to do the trick! > > Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> > > > Also, what .config are you using? > > Attached. > > Probably CONFIG_DEBUG_VIRTUAL=y is what you're missing. > > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds
On Wed, Aug 14, 2019 at 01:34:49PM +0530, Bhupesh Sharma wrote: > I still see the following issue on a 48-bit hardware (i.e. _non_ > ARMv8.2 hardware) with branch 'for-next/52-bit-kva' with commit > d2d73d2fef421ca0d4 as the HEAD: Have you tried the patches I posted here: http://lists.infradead.org/pipermail/linux-arm-kernel/2019-August/673315.html ? Whilst they're being reviewed, I've dropped the 52-bit branch from linux-next (for-next/core) so that people don't keep running into this. Will
On Wed, Aug 14, 2019 at 1:51 PM Will Deacon <will@kernel.org> wrote: > > On Wed, Aug 14, 2019 at 01:34:49PM +0530, Bhupesh Sharma wrote: > > I still see the following issue on a 48-bit hardware (i.e. _non_ > > ARMv8.2 hardware) with branch 'for-next/52-bit-kva' with commit > > d2d73d2fef421ca0d4 as the HEAD: > > Have you tried the patches I posted here: > > http://lists.infradead.org/pipermail/linux-arm-kernel/2019-August/673315.html > > ? > > Whilst they're being reviewed, I've dropped the 52-bit branch from > linux-next (for-next/core) so that people don't keep running into this. Thanks will try the above and get back with my results. However just to make sure that the 52-bit changes are tested properly (before landing up linux-next) - as we had issues with the 52-bit User space VA + PA changes in the past (which broke userspace), I was wondering if we can have a dedicated branch to have the v5 patches from Steve + fixes, so that they can be easily tested and issues (if any) reported with easy reference. Or, if such a branch already exists, kindly share the pointer to the same as well. Thanks, Bhupesh
[+Mark] On Wed, Aug 14, 2019 at 05:29:09PM +0530, Bhupesh Sharma wrote: > On Wed, Aug 14, 2019 at 1:51 PM Will Deacon <will@kernel.org> wrote: > > > > On Wed, Aug 14, 2019 at 01:34:49PM +0530, Bhupesh Sharma wrote: > > > I still see the following issue on a 48-bit hardware (i.e. _non_ > > > ARMv8.2 hardware) with branch 'for-next/52-bit-kva' with commit > > > d2d73d2fef421ca0d4 as the HEAD: > > > > Have you tried the patches I posted here: > > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2019-August/673315.html > > > > ? > > > > Whilst they're being reviewed, I've dropped the 52-bit branch from > > linux-next (for-next/core) so that people don't keep running into this. > > Thanks will try the above and get back with my results. > > However just to make sure that the 52-bit changes are tested properly > (before landing up linux-next) - as we had issues with the 52-bit User > space VA + PA changes in the past (which broke userspace), I was > wondering if we can have a dedicated branch to have the v5 patches > from Steve + fixes, so that they can be easily tested and issues (if > any) reported with easy reference. > > Or, if such a branch already exists, kindly share the pointer to the > same as well. I've pushed the current round of fixes on top of: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/52-bit-kva Mark has spotted a couple of other issues, but they shoudn't hold up your testing (although I'm going to hold off putting this back into -next until we've got them resolved). Mark -- please use the branch above as a basis for any additional fixes. HEAD should be d0b3c32ed922. Thanks, Will
This patch series adds support for 52-bit kernel VAs using some of the machinery already introduced by the 52-bit userspace VA code in 5.0. As 52-bit virtual address support is an optional hardware feature, software support for 52-bit kernel VAs needs to be deduced at early boot time. If HW support is not available, the kernel falls back to 48-bit. A significant proportion of this series focuses on "de-constifying" VA_BITS related constants. In order to allow for a KASAN shadow that changes size at boot time, one must fix the KASAN_SHADOW_END for both 48 & 52-bit VAs and "grow" the start address. Also, it is highly desirable to maintain the same function addresses in the kernel .text between VA sizes. Both of these requirements necessitate us to flip the kernel address space halves s.t. the direct linear map occupies the lower addresses. In V5 of this series the, now redundant, vabits_user was removed by an extra patch. In V4 of this series, an extra documentation patch is added to explain both the layout of the memory and the implementation of 52-bit support. Also added is a guard region after VMEMMAP to avoid ambiguity with IS_ERR style pointers. Finally the bitmask optimisations for VMEMMAP and PAGE_OFFSET are replaced with addition/subtraction in a new first patch for the series. In V3 of this series, the 52-bit user/48-bit kernel option is removed and we are left with a single 52-bit VA option instead. The offset_ttbr1 conditional logic has been re-worked to directly read a system register rather than rely on the alternative framework (I couldn't actually see a hotpath calling offset_ttbr1 and some parts of the early boot relied on offset_ttbr1 before the alternatives framework was called). Also some spurious de-constifying changes have been removed. In V2 of this series (apologies for the long delay from V1), the major change is that PAGE_OFFSET is retained as a constant. This allows for much faster virt_to_page computations. This is achieved by expanding the size of the VMEMMAP region to accommodate a disjoint 52-bit/48-bit direct linear map. This has been found to work well in my testing, but I would appreciate any feedback on this if it needs changing. To aid with git bisect, this logic is broken down into a few smaller patches Steve Capper (12): arm64: mm: Remove bit-masking optimisations for PAGE_OFFSET and VMEMMAP_START arm64: mm: Flip kernel VA space arm64: kasan: Switch to using KASAN_SHADOW_OFFSET arm64: dump: De-constify VA_START and KASAN_SHADOW_START arm64: mm: Introduce VA_BITS_MIN arm64: mm: Introduce vabits_actual arm64: mm: Logic to make offset_ttbr1 conditional arm64: mm: Separate out vmemmap arm64: mm: Modify calculation of VMEMMAP_SIZE arm64: mm: Introduce 52-bit Kernel VAs arm64: mm: Remove vabits_user docs: arm64: Add layout and 52-bit info to memory document Documentation/arm64/kasan-offsets.sh | 27 ++++++ Documentation/arm64/memory.rst | 123 +++++++++++++++++++------ arch/arm64/Kconfig | 31 +++++-- arch/arm64/Makefile | 8 -- arch/arm64/include/asm/assembler.h | 17 +++- arch/arm64/include/asm/efi.h | 4 +- arch/arm64/include/asm/kasan.h | 11 +-- arch/arm64/include/asm/memory.h | 58 +++++++----- arch/arm64/include/asm/mmu_context.h | 4 +- arch/arm64/include/asm/pgtable-hwdef.h | 2 +- arch/arm64/include/asm/pgtable.h | 6 +- arch/arm64/include/asm/pointer_auth.h | 2 +- arch/arm64/include/asm/processor.h | 4 +- arch/arm64/kernel/head.S | 12 +-- arch/arm64/kernel/hibernate-asm.S | 8 +- arch/arm64/kernel/hibernate.c | 2 +- arch/arm64/kernel/kaslr.c | 6 +- arch/arm64/kvm/va_layout.c | 14 +-- arch/arm64/mm/dump.c | 22 ++++- arch/arm64/mm/fault.c | 5 +- arch/arm64/mm/init.c | 29 ++++-- arch/arm64/mm/kasan_init.c | 9 +- arch/arm64/mm/mmu.c | 9 +- arch/arm64/mm/proc.S | 11 ++- 24 files changed, 289 insertions(+), 135 deletions(-) create mode 100644 Documentation/arm64/kasan-offsets.sh