| Message ID | 20221117132423.1252942-1-ardb@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | arm64: Enable LPA2 support for 16k pages | expand |
Hi Ard, On Thu, Nov 17, 2022 at 02:24:16PM +0100, Ard Biesheuvel wrote: > Enable support for LPA2 when running with 16k pages. Unlike with 4k > pages, this does not require adding support for 5 level paging, but > beyond that, there is no fundamental difference between LPA2 support on > 4k or 16k pages. We have some patches already from Anshuman, targeting both 4K and 16K pages: https://lore.kernel.org/r/1632998116-11552-1-git-send-email-anshuman.khandual@arm.com I don't think they've been rebased on top of 6.1-rcX though. Could you please liaise with Anshuman and agree on a way forward? I'd rather only review a single series if they do the same thing. I have a preference for a more complete solution (4K and 16K) rather than just 16K pages. I think we can even ignore some corner cases like 39-bit VA (if anyone is asking, we could do it later but it doesn't seem realistic). And a question for Anshuman: do you plan to refresh your series? Thanks.
On Fri, 18 Nov 2022 at 11:38, Catalin Marinas <catalin.marinas@arm.com> wrote: > > Hi Ard, > > On Thu, Nov 17, 2022 at 02:24:16PM +0100, Ard Biesheuvel wrote: > > Enable support for LPA2 when running with 16k pages. Unlike with 4k > > pages, this does not require adding support for 5 level paging, but > > beyond that, there is no fundamental difference between LPA2 support on > > 4k or 16k pages. > > We have some patches already from Anshuman, targeting both 4K and 16K > pages: > > https://lore.kernel.org/r/1632998116-11552-1-git-send-email-anshuman.khandual@arm.com > Ah right - I was aware that Anshuman had been looking into this as well, but I did not realise working code had been sent to the list. That series doesn't cover 5 level paging yet, right? > I don't think they've been rebased on top of 6.1-rcX though. Could you > please liaise with Anshuman and agree on a way forward? I'd rather only > review a single series if they do the same thing. I have a preference > for a more complete solution (4K and 16K) rather than just 16K pages. I > think we can even ignore some corner cases like 39-bit VA (if anyone is > asking, we could do it later but it doesn't seem realistic). > If we can agree that we don't need more than 48 bits for the ID map (at least for the time being), this all fits quite nicely on top of the boot code refactor that i sent out last week, where the code in head.S is only responsible for creating the [initial] ID map, and everything else is done from C code. I'll have a look today at how much additional work is needed on top of this series to accommodate 4k 52-bit VA and PA support, but beyond adding p4d handling in some places, I think it should be fairly limited. > And a question for Anshuman: do you plan to refresh your series? > Yeah let's align on a way forward here. Apologies for stepping on this, I wasn't aware how much actual code you had already written.
On 18/11/2022 10:50, Ard Biesheuvel wrote: > On Fri, 18 Nov 2022 at 11:38, Catalin Marinas <catalin.marinas@arm.com> wrote: >> >> Hi Ard, >> >> On Thu, Nov 17, 2022 at 02:24:16PM +0100, Ard Biesheuvel wrote: >>> Enable support for LPA2 when running with 16k pages. Unlike with 4k >>> pages, this does not require adding support for 5 level paging, but >>> beyond that, there is no fundamental difference between LPA2 support on >>> 4k or 16k pages. >> >> We have some patches already from Anshuman, targeting both 4K and 16K >> pages: >> >> https://lore.kernel.org/r/1632998116-11552-1-git-send-email-anshuman.khandual@arm.com FYI, I also have a set of patches that implements LPA2 (4K and 16K pages including 5 levels for 4K case) for kvm stage2 and hyp stage1. This works independently of the kernel stage1 work, but I've been waiting for Anshuman's rebase for 6.1 to do my final testing before submitting to the list (without those patches I can't test the stage2 OA >48 bits case). Hope I'm not stepping on anyone's toes - shout if so. Thanks, Ryan
On 11/18/22 16:08, Catalin Marinas wrote: > Hi Ard, > > On Thu, Nov 17, 2022 at 02:24:16PM +0100, Ard Biesheuvel wrote: >> Enable support for LPA2 when running with 16k pages. Unlike with 4k >> pages, this does not require adding support for 5 level paging, but >> beyond that, there is no fundamental difference between LPA2 support on >> 4k or 16k pages. > We have some patches already from Anshuman, targeting both 4K and 16K > pages: > > https://lore.kernel.org/r/1632998116-11552-1-git-send-email-anshuman.khandual@arm.com > > I don't think they've been rebased on top of 6.1-rcX though. Could you > please liaise with Anshuman and agree on a way forward? I'd rather only > review a single series if they do the same thing. I have a preference > for a more complete solution (4K and 16K) rather than just 16K pages. I > think we can even ignore some corner cases like 39-bit VA (if anyone is > asking, we could do it later but it doesn't seem realistic). > > And a question for Anshuman: do you plan to refresh your series? This contains above series rebased on v6.1-rc1, but without an working idmap though, which prevents booting the kernel loaded beyond 48 bits PA. https://gitlab.arm.com/linux-arm/linux-anshuman/-/commits/lpa2/rfc/v2/ But in the local tree, fixed 'init_idmap_pg_dir' to boot the kernel beyond 48 bit physical address for [4K|48VA|52PA], but still working towards getting the runtime 'idmap_pg_dir' right, although the kernel still boots if 'init_pg_dir' is used instead in all such places. Regardless, I will post the series early next week for all of us to sync up. - Anshuman
On 11/18/22 16:20, Ard Biesheuvel wrote: > On Fri, 18 Nov 2022 at 11:38, Catalin Marinas <catalin.marinas@arm.com> wrote: >> >> Hi Ard, >> >> On Thu, Nov 17, 2022 at 02:24:16PM +0100, Ard Biesheuvel wrote: >>> Enable support for LPA2 when running with 16k pages. Unlike with 4k >>> pages, this does not require adding support for 5 level paging, but >>> beyond that, there is no fundamental difference between LPA2 support on >>> 4k or 16k pages. >> >> We have some patches already from Anshuman, targeting both 4K and 16K >> pages: >> >> https://lore.kernel.org/r/1632998116-11552-1-git-send-email-anshuman.khandual@arm.com >> > > Ah right - I was aware that Anshuman had been looking into this as > well, but I did not realise working code had been sent to the list. > > That series doesn't cover 5 level paging yet, right? The posted series last year was to enable 52 bit PA for all VA configs on 4K and 16K page sizes. There was a fix (and other changes) to idmap which enabled two additional idmap levels, to support much spaced VA-PA configs for FEAT_LPA2, but now those idmap changes need to be reworked after your recent boot code changes. But it never enabled 52 bit VA (although I had some local changes) which would have required proper 5 level paging. > >> I don't think they've been rebased on top of 6.1-rcX though. Could you >> please liaise with Anshuman and agree on a way forward? I'd rather only >> review a single series if they do the same thing. I have a preference >> for a more complete solution (4K and 16K) rather than just 16K pages. I >> think we can even ignore some corner cases like 39-bit VA (if anyone is >> asking, we could do it later but it doesn't seem realistic). >> > > If we can agree that we don't need more than 48 bits for the ID map > (at least for the time being), this all fits quite nicely on top of > the boot code refactor that i sent out last week, where the code in > head.S is only responsible for creating the [initial] ID map, and > everything else is done from C code. I have some changes to 'init_idmap_pg_dir' creation in the assembly code i.e create_idmap which gets [4K|52PA|48VA] to boot with kernel loaded beyond 48 bits PA. The problem is, it gets stuck at "smp: Bringing up secondary CPUs .." as the runtime 'idmap_pg_dir' created with C code create_idmap() does not handle (does not create required additional pgtable levels) when VA=48. Something else I discovered is that current 'idmap_pg_dir' does not work with an existing config [64K|52PA|48PA] when vmlinux is loaded beyond 48 bits PA. After fixing this existing problem, my plan was to enable it for FEAT_LPA2 configs on 4K/16K. > > I'll have a look today at how much additional work is needed on top of > this series to accommodate 4k 52-bit VA and PA support, but beyond > adding p4d handling in some places, I think it should be fairly > limited. > >> And a question for Anshuman: do you plan to refresh your series? >> > > Yeah let's align on a way forward here. Apologies for stepping on > this, I wasn't aware how much actual code you had already written. No worries. Let sync up on Monday, or any other time suitable for you. I can walk you through all that I have, all that planed etc, then we could figure out how to proceed further.
Enable support for LPA2 when running with 16k pages. Unlike with 4k pages, this does not require adding support for 5 level paging, but beyond that, there is no fundamental difference between LPA2 support on 4k or 16k pages. There are a few rough edges that make this less straight-forward than it was to enable LVA on 64k pages: even though also in this case, we can rely on statically sized root level page tables, we cannot advance the TTBR1 pointer to the pgdir entry that covers the start of the 48-bit addressable like we do on LVA, as the resulting address is not 64 byte aligned, which is a requirement for TTBR registers. Another slight complication is that the repurposed physical address bits in the page table descriptors were not RES0 before, and so there is now a big global switch (called TCR.DS) which controls how all page table descriptors are interpreted. This requires some extra care in the PTE conversion helpers, and additional handling in the boot code to ensure that we set TCR.DS safely if supported (and not overridden) This series applies onto some of my previous work that is still in flight, so these patches will not apply in isolation. Complete branch can be found here: https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm64-16k-lpa2 Tested on QEMU with -cpu max and lpa2 both off and on, as well as using the arm64.nolva override kernel command line parameter. Note that this requires a QEMU patch that has not been merged yet: https://lore.kernel.org/qemu-devel/20221116170316.259695-1-ardb@kernel.org/ Cc: Marc Zyngier <maz@kernel.org> Cc: Will Deacon <will@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Kees Cook <keescook@chromium.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Mark Brown <broonie@kernel.org> Cc: Anshuman Khandual <anshuman.khandual@arm.com> Cc: Richard Henderson <richard.henderson@linaro.org> Ard Biesheuvel (7): arm64: ptdump: Disregard unaddressable VA space arm64: mm: Disable all 52-bit virtual addressing support with arm64.nolva arm64: mm: Wire up TCR.DS bit to PTE shareability fields arm64: mm: Support use of 52-bit pgdirs on 48-bit/16k systems arm64: mm: Add LPA2 support to phys<->pte conversion routines arm64: Enable LPA2 at boot if supported by the system arm64: Enable 52-bit virtual addressing for 16k granule configs arch/arm64/Kconfig | 6 +- arch/arm64/include/asm/assembler.h | 33 ++----- arch/arm64/include/asm/cpufeature.h | 1 + arch/arm64/include/asm/mmu.h | 18 ++++ arch/arm64/include/asm/pgtable-hwdef.h | 11 ++- arch/arm64/include/asm/pgtable-prot.h | 18 +++- arch/arm64/include/asm/pgtable.h | 5 +- arch/arm64/kernel/cpufeature.c | 27 ++++- arch/arm64/kernel/image-vars.h | 3 + arch/arm64/kernel/pi/idreg-override.c | 26 +++++ arch/arm64/kernel/pi/map_kernel.c | 103 +++++++++++++++++++- arch/arm64/mm/mmap.c | 4 + arch/arm64/mm/mmu.c | 2 + arch/arm64/mm/proc.S | 13 +++ arch/arm64/mm/ptdump.c | 4 +- 15 files changed, 229 insertions(+), 45 deletions(-)