This series enables 52 bits PA support for 4K and 16K page configs via
existing CONFIG_ARM64_PA_BITS_52, utilizing a new arch feature FEAT_LPA2
which is available from ARM v8.7. IDMAP needs changes to accommodate two
new level of page tables in certain scenarios like (4K|39VA|52PA) but the
same problem also exists for (16K|36VA|48PA) which needs fixing. I have
sent a fix for 16K case [1] and later will enable it for FEAT_LPA2 as well.
This series applies on v5.15-rc3.
Testing:
Build and boot tested (individual patches) on all existing and new
FEAT_LPA2 enabled config combinations.
Pending:
- Enable IDMAP for FEAT_LPA2
- Enable 52 bit VA range on 4K/16K page sizes
- Evaluate KVM and SMMU impacts from FEAT_LPA2
[1] https://lore.kernel.org/all/1632807225-20189-1-git-send-email-anshuman.khandual@arm.com/
Changes in RFC V3:
- protection_map[] gets reinitialized in platform to avoid build failure per Catalin
- Added __cpu_secondary_check52bitpa()
- Added FEAT_LPA2 support during KVM stage-2 translation
- Updated description for ARM64_PA_BITS_52 per Catalin
- Added tags from last version
Changes in RFC V2:
https://lore.kernel.org/all/1627281445-12445-1-git-send-email-anshuman.khandual@arm.com/
- Changed FEAT_LPA2 presence qualifying criteria wrt ID_AA64MMFR0_TGRAN_LPA2
- Changed FEAT_LPA2 specific encoding which drops the additional tmp variable
- Fixed [phys|pte]_to_[pte|phys]() helpers when FEAT_LPA2 is implemented
Changes in RFC V1:
https://lore.kernel.org/lkml/1626229291-6569-1-git-send-email-anshuman.khandual@arm.com/
Anshuman Khandual (13):
arm64/mm: Dynamically initialize protection_map[]
arm64/mm: Consolidate TCR_EL1 fields
arm64/mm: Add FEAT_LPA2 specific TCR_EL1.DS field
arm64/mm: Add FEAT_LPA2 specific VTCR_EL2.DS field
arm64/mm: Add FEAT_LPA2 specific ID_AA64MMFR0.TGRAN[2]
arm64/mm: Add CONFIG_ARM64_PA_BITS_52_[LPA|LPA2]
arm64/mm: Add FEAT_LPA2 specific encoding
arm64/mm: Detect and enable FEAT_LPA2
arm64/mm: Add __cpu_secondary_check52bitpa()
arm64/mm: Add FEAT_LPA2 specific PTE_SHARED and PMD_SECT_S
arm64/mm: Add FEAT_LPA2 specific fallback (48 bits PA) when not implemented
arm64/mm: Enable CONFIG_ARM64_PA_BITS_52 on CONFIG_ARM64_[4K|16K]_PAGES
KVM: arm64: Enable FEAT_LPA2 based 52 bits IPA size on 4K and 16K
arch/arm64/Kconfig | 17 +++++++----
arch/arm64/include/asm/assembler.h | 42 +++++++++++++++++++++------
arch/arm64/include/asm/kernel-pgtable.h | 4 +--
arch/arm64/include/asm/kvm_arm.h | 1 +
arch/arm64/include/asm/kvm_pgtable.h | 10 ++++++-
arch/arm64/include/asm/memory.h | 1 +
arch/arm64/include/asm/pgtable-hwdef.h | 28 ++++++++++++++----
arch/arm64/include/asm/pgtable-prot.h | 34 +++++++++++-----------
arch/arm64/include/asm/pgtable.h | 18 ++++++++++--
arch/arm64/include/asm/smp.h | 1 +
arch/arm64/include/asm/sysreg.h | 9 +++---
arch/arm64/kernel/head.S | 51 +++++++++++++++++++++++++++++++++
arch/arm64/kernel/smp.c | 2 ++
arch/arm64/kvm/hyp/pgtable.c | 25 ++++++++++++++--
arch/arm64/kvm/reset.c | 14 ++++++---
arch/arm64/mm/init.c | 22 ++++++++++++++
arch/arm64/mm/mmu.c | 3 ++
arch/arm64/mm/pgd.c | 2 +-
arch/arm64/mm/proc.S | 11 ++++++-
arch/arm64/mm/ptdump.c | 26 +++++++++++++++--
20 files changed, 265 insertions(+), 56 deletions(-)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Going forward some protection_map[] elements (i.e __PXXX and __SXXX) would
contain a runtime variable with FEAT_LPA2 enabled, preventing a successful
build because of their current static initialization. This change prevents
the problem via assigning a dummy protection value i.e __pgprot(0) to all
__PXXX and __SXXX elements which builds successfully but later updates the
protection_map[] array in platform mem_init(). __pgprot(0) does not cause
any problem because vm_get_page_prot() which uses protection_map[] should
never be called before platform mem_init().
Signed-off-by: Anshuman Khandual <redacted>
---
arch/arm64/include/asm/pgtable-prot.h | 34 +++++++++++++++++-----------------
arch/arm64/mm/init.c | 22 ++++++++++++++++++++++
2 files changed, 39 insertions(+), 17 deletions(-)
This renames and moves SYS_TCR_EL1_TCMA1 and SYS_TCR_EL1_TCMA0 definitions
into pgtable-hwdef.h thus consolidating all TCR fields in a single header.
This does not cause any functional change.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Anshuman Khandual <redacted>
---
arch/arm64/include/asm/pgtable-hwdef.h | 2 ++
arch/arm64/include/asm/sysreg.h | 4 ----
arch/arm64/mm/proc.S | 2 +-
3 files changed, 3 insertions(+), 5 deletions(-)
As per ARM ARM (0487G.A) TCR_EL1.DS fields controls whether 52 bit input
and output address get supported on 4K and 16K page size configuration,
when FEAT_LPA2 is known to have been implemented. This adds TCR_DS field
definition which would be used when FEAT_LPA2 gets enabled.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Anshuman Khandual <redacted>
---
arch/arm64/include/asm/pgtable-hwdef.h | 1 +
1 file changed, 1 insertion(+)
As per ARM ARM (0487G.A) VTCR_EL2.DS fields controls whether 52 bit IPA and
output physical address get supported on 4K and 16K page size configuration
when FEAT_LPA2 is known to have been implemented. This adds VTCR_DS field
definition which would be used when FEAT_LPA2 gets enabled in Stage-2.
Signed-off-by: Anshuman Khandual <redacted>
---
arch/arm64/include/asm/kvm_arm.h | 1 +
1 file changed, 1 insertion(+)
PAGE_SIZE support is tested against possible minimum and maximum values for
its respective ID_AA64MMFR0.TGRAN field, depending on whether it is signed
or unsigned. But then FEAT_LPA2 implementation needs to be validated for 4K
and 16K page sizes via feature specific ID_AA64MMFR0.TGRAN values. Hence it
adds FEAT_LPA2 specific ID_AA64MMFR0.TGRAN[2] values per ARM ARM (0487G.A).
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Anshuman Khandual <redacted>
---
arch/arm64/include/asm/sysreg.h | 5 +++++
1 file changed, 5 insertions(+)
Going forward, CONFIG_ARM64_PA_BITS_52 could be enabled on a system via two
different architecture features i.e FEAT_LPA for CONFIG_ARM64_64K_PAGES and
FEAT_LPA2 for CONFIG_ARM64_[4K|16K]_PAGES. But CONFIG_ARM64_PA_BITS_52 is
exclussively available on 64K page size config currently, which needs to be
freed up for other page size configs to use when FEAT_LPA2 gets enabled.
To achieve CONFIG_ARM64_PA_BITS_52 and CONFIG_ARM64_64K_PAGES decoupling,
and also to reduce #ifdefs while navigating various page size configs, this
adds two internal config options CONFIG_ARM64_PA_BITS_52_[LPA|LPA2]. While
here it also converts existing 64K page size based FEAT_LPA implementations
to use CONFIG_ARM64_PA_BITS_52_LPA. TTBR representation remains same for
both FEAT_LPA and FEAT_LPA2. No functional change for 64K page size config.
Signed-off-by: Anshuman Khandual <redacted>
---
arch/arm64/Kconfig | 7 +++++++
arch/arm64/include/asm/assembler.h | 12 ++++++------
arch/arm64/include/asm/pgtable-hwdef.h | 7 ++++---
arch/arm64/include/asm/pgtable.h | 6 +++---
arch/arm64/mm/pgd.c | 2 +-
5 files changed, 21 insertions(+), 13 deletions(-)
FEAT_LPA2 requires different PTE representation formats for both 4K and 16K
page size config. This adds FEAT_LPA2 specific new PTE encodings as per ARM
ARM (0487G.A) which updates [pte|phys]_to_[phys|pte](). The updated helpers
would be used when FEAT_LPA2 gets enabled via CONFIG_ARM64_PA_BITS_52 on 4K
and 16K page size. Although TTBR encoding and phys_to_ttbr() helper remains
the same as FEAT_LPA for FEAT_LPA2 as well. It updates 'phys_to_pte' helper
to accept a temporary variable and changes impacted call sites.
Signed-off-by: Anshuman Khandual <redacted>
---
arch/arm64/include/asm/assembler.h | 14 +++++++++++---
arch/arm64/include/asm/pgtable-hwdef.h | 4 ++++
arch/arm64/include/asm/pgtable.h | 4 ++++
3 files changed, 19 insertions(+), 3 deletions(-)
Detect FEAT_LPA2 implementation early enough during boot when requested via
CONFIG_ARM64_PA_BITS_52_LPA2 and remember in a variable arm64_lpa2_enabled.
This variable could then be used to turn on TCR_EL1.TCR_DS effecting the 52
bits PA range or fall back to default 48 bits PA range if FEAT_LPA2 feature
was requested but found not to be implemented.
Signed-off-by: Anshuman Khandual <redacted>
---
arch/arm64/include/asm/memory.h | 1 +
arch/arm64/kernel/head.S | 15 +++++++++++++++
arch/arm64/mm/mmu.c | 3 +++
arch/arm64/mm/proc.S | 9 +++++++++
4 files changed, 28 insertions(+)
@@ -178,6 +178,7 @@#include<asm/bug.h>externu64vabits_actual;+externu64arm64_lpa2_enabled;externs64memstart_addr;/* PHYS_OFFSET - the physical address of the start of memory. */
FEAT_LPA2 enabled systems needs to test ID_AA64MMFR0.TGRAN value to ensure
that 52 bit PA range is supported across all secondary CPUs both for 4K and
16K configs. This adds a new __cpu_secondary_check52bitva check along with
a corresponding reason code CPU_STUCK_REASON_52_BIT_PA. This will identify
the exact reason in case the system gets stuck after detecting a secondary
CPU that does not support 52 bit PA.
Signed-off-by: Anshuman Khandual <redacted>
---
arch/arm64/include/asm/smp.h | 1 +
arch/arm64/kernel/head.S | 21 +++++++++++++++++++++
arch/arm64/kernel/smp.c | 2 ++
3 files changed, 24 insertions(+)
@@ -770,6 +771,26 @@ SYM_FUNC_START(__cpu_secondary_check52bitva)2:retSYM_FUNC_END(__cpu_secondary_check52bitva)+SYM_FUNC_START(__cpu_secondary_check52bitpa)+#ifdef CONFIG_ARM64_PA_BITS_52_LPA2+ldr_lx0,arm64_lpa2_enabled+cmpx2,#1+b.ne2f++mrsx0,ID_AA64MMFR0_EL1+ubfxx0,x0,#ID_AA64MMFR0_TGRAN_SHIFT, 4+cmpx0,#ID_AA64MMFR0_TGRAN_LPA2+b.ge2f++update_early_cpu_boot_status\+CPU_STUCK_IN_KERNEL|CPU_STUCK_REASON_52_BIT_PA,x0,x1+1:wfe+wfi+b1b+#endif+2:ret+SYM_FUNC_END(__cpu_secondary_check52bitpa)+SYM_FUNC_START_LOCAL(__no_granule_support)/*IndicatethatthisCPUcan't boot and is stuck in the kernel */update_early_cpu_boot_status\
@@ -164,6 +164,8 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)if(status&CPU_STUCK_REASON_NO_GRAN){pr_crit("CPU%u: does not support %luK granule\n",cpu,PAGE_SIZE/SZ_1K);+if(status&CPU_STUCK_REASON_52_BIT_PA)+pr_crit("CPU%u: does not support 52-bit PAs\n",cpu);}cpus_stuck_in_kernel++;break;
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PTE[9:8] which holds the sharability attribute bits SH[1:0] could collide
with PA[51:50] when CONFIG_ARM64_PA_BITS_52 is enabled but then FEAT_LPA2
is not detected during boot. Dropping PTE_SHARED and PMD_SECT_S attributes
completely in this scenario will create non-shared page table entries which
would cause regression.
Instead just define PTE_SHARED and PMD_SECT_S after accounting for runtime
'arm64_lpa2_enable', thus maintaining required sharability attributes for
both kernel and user space page table entries. This updates ptdump handling
for page table entry shared attributes accommodating FEAT_LPA2 scenarios.
Signed-off-by: Anshuman Khandual <redacted>
---
arch/arm64/include/asm/kernel-pgtable.h | 4 ++--
arch/arm64/include/asm/pgtable-hwdef.h | 12 ++++++++++--
arch/arm64/kernel/head.S | 15 +++++++++++++++
arch/arm64/mm/ptdump.c | 26 ++++++++++++++++++++++++--
4 files changed, 51 insertions(+), 6 deletions(-)
CONFIG_ARM64_PA_BITS_52 build kernels need to fallback for 48 bits PA range
encodings when FEAT_LPA2 is not implemented i.e TCR_EL1.DS could not be set
. Hence modify applicable PTE and TTBR encoding helpers to accommodate the
scenario via 'arm64_lpa2_enabled'.
Signed-off-by: Anshuman Khandual <redacted>
---
arch/arm64/include/asm/assembler.h | 16 ++++++++++++++++
arch/arm64/include/asm/pgtable-hwdef.h | 2 ++
arch/arm64/include/asm/pgtable.h | 12 ++++++++++--
3 files changed, 28 insertions(+), 2 deletions(-)
All required FEAT_LPA2 components for 52 bit PA range are already in place.
Just enable CONFIG_ARM64_PA_BITS_52 on 4K and 16K pages which would select
CONFIG_ARM64_PA_BITS_52_LPA2 activating 52 bit PA range via FEAT_LPA2.
Signed-off-by: Anshuman Khandual <redacted>
---
arch/arm64/Kconfig | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
Stage-2 FEAT_LPA2 support is independent and also orthogonal to FEAT_LPA2
support either in Stage-1 or in the host kernel. Stage-2 IPA range support
is evaluated from the platform via ID_AA64MMFR0_TGRAN_2_SUPPORTED_LPA2 and
gets enabled regardless of Stage-1 translation.
Signed-off-by: Anshuman Khandual <redacted>
---
arch/arm64/include/asm/kvm_pgtable.h | 10 +++++++++-
arch/arm64/kvm/hyp/pgtable.c | 25 +++++++++++++++++++++++--
arch/arm64/kvm/reset.c | 14 ++++++++++----
3 files changed, 42 insertions(+), 7 deletions(-)
Stage-2 FEAT_LPA2 support is independent and also orthogonal to FEAT_LPA2
support either in Stage-1 or in the host kernel. Stage-2 IPA range support
is evaluated from the platform via ID_AA64MMFR0_TGRAN_2_SUPPORTED_LPA2 and
gets enabled regardless of Stage-1 translation.
Signed-off-by: Anshuman Khandual <redacted>
---
arch/arm64/include/asm/kvm_pgtable.h | 10 +++++++++-
arch/arm64/kvm/hyp/pgtable.c | 25 +++++++++++++++++++++++--
arch/arm64/kvm/reset.c | 14 ++++++++++----
3 files changed, 42 insertions(+), 7 deletions(-)
Having to do a function call just for this test seems bad, specially
for something that is used so often on the fault path.
Why can't this be made a normal capability that indicates LPA support
for the current page size?
*/- if (PAGE_SIZE != SZ_64K)- parange = min(parange, (unsigned int)ID_AA64MMFR0_PARANGE_48);+ if (PAGE_SIZE != SZ_64K) {+ if (tgran == ID_AA64MMFR0_TGRAN_2_SUPPORTED_LPA2)+ set_kvm_lpa2_enabled();+ else+ parange = min(parange, (unsigned int)ID_AA64MMFR0_PARANGE_48);+ } /* * Check with ARMv8.5-GTG that our PAGE_SIZE is supported at * Stage-2. If not, things will stop very quickly. */- switch (cpuid_feature_extract_unsigned_field(mmfr0, ID_AA64MMFR0_TGRAN_2_SHIFT)) {+ switch (tgran) { case ID_AA64MMFR0_TGRAN_2_SUPPORTED_NONE: kvm_err("PAGE_SIZE not supported at Stage-2, giving up\n"); return -EINVAL;
Another thing I don't see is how you manage TLB invalidation by level
now that we gain a level 0 at 4kB, breaking the current assumptions
encoded in __tlbi_level().
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Stage-2 FEAT_LPA2 support is independent and also orthogonal to FEAT_LPA2
support either in Stage-1 or in the host kernel. Stage-2 IPA range support
is evaluated from the platform via ID_AA64MMFR0_TGRAN_2_SUPPORTED_LPA2 and
gets enabled regardless of Stage-1 translation.
Signed-off-by: Anshuman Khandual <redacted>
---
arch/arm64/include/asm/kvm_pgtable.h | 10 +++++++++-
arch/arm64/kvm/hyp/pgtable.c | 25 +++++++++++++++++++++++--
arch/arm64/kvm/reset.c | 14 ++++++++++----
3 files changed, 42 insertions(+), 7 deletions(-)
Having to do a function call just for this test seems bad, specially
for something that is used so often on the fault path.
Why can't this be made a normal capability that indicates LPA support
for the current page size?
Although I could look into making this a normal capability check, would
not a static key based implementation be preferred if the function call
based construct here is too expensive ?
Originally, avoided capability method for stage-2 because it would have
been difficult in stage-1 where the FEAT_LPA2 detection is required way
earlier during boot before cpu capability comes up. Hence just followed
a simple variable method both for stage-1 and stage-2 keeping it same.
quoted
+ pa |= FIELD_GET(KVM_PTE_ADDR_51_50, pte) << 50;
Where are bits 48 and 49?
Unlike the current FEAT_LPA feature, bits 48 and 49 are part of the PA
itself. Only the bits 50 and 51 move into bits 8 and 9, while creating
a PTE.
*/- if (PAGE_SIZE != SZ_64K)- parange = min(parange, (unsigned int)ID_AA64MMFR0_PARANGE_48);+ if (PAGE_SIZE != SZ_64K) {+ if (tgran == ID_AA64MMFR0_TGRAN_2_SUPPORTED_LPA2)+ set_kvm_lpa2_enabled();+ else+ parange = min(parange, (unsigned int)ID_AA64MMFR0_PARANGE_48);+ } /* * Check with ARMv8.5-GTG that our PAGE_SIZE is supported at * Stage-2. If not, things will stop very quickly. */- switch (cpuid_feature_extract_unsigned_field(mmfr0, ID_AA64MMFR0_TGRAN_2_SHIFT)) {+ switch (tgran) { case ID_AA64MMFR0_TGRAN_2_SUPPORTED_NONE: kvm_err("PAGE_SIZE not supported at Stage-2, giving up\n"); return -EINVAL;
Another thing I don't see is how you manage TLB invalidation by level
now that we gain a level 0 at 4kB, breaking the current assumptions
encoded in __tlbi_level().
Right, I guess something like this (not build tested) will be required as
level 0 for 4K and level 1 for 16K would only make sense when FEAT_LPA2 is
implemented, otherwise it will fallback to the default behaviour i.e table
level hint was not provided (TTL[3:2] is 0b00). Is there any other concern
which I might be missing here ?
Stage-2 FEAT_LPA2 support is independent and also orthogonal to FEAT_LPA2
support either in Stage-1 or in the host kernel. Stage-2 IPA range support
is evaluated from the platform via ID_AA64MMFR0_TGRAN_2_SUPPORTED_LPA2 and
gets enabled regardless of Stage-1 translation.
Signed-off-by: Anshuman Khandual <redacted>
---
arch/arm64/include/asm/kvm_pgtable.h | 10 +++++++++-
arch/arm64/kvm/hyp/pgtable.c | 25 +++++++++++++++++++++++--
arch/arm64/kvm/reset.c | 14 ++++++++++----
3 files changed, 42 insertions(+), 7 deletions(-)
Having to do a function call just for this test seems bad, specially
for something that is used so often on the fault path.
Why can't this be made a normal capability that indicates LPA support
for the current page size?
Although I could look into making this a normal capability check, would
not a static key based implementation be preferred if the function call
based construct here is too expensive ?
A capability *is* a static key. Specially if you make it final.
Originally, avoided capability method for stage-2 because it would have
been difficult in stage-1 where the FEAT_LPA2 detection is required way
earlier during boot before cpu capability comes up. Hence just followed
a simple variable method both for stage-1 and stage-2 keeping it same.
I think you'll have to find a way to make it work with a capability
for S1 too. Capabilities can be used even when not final, and you may
have to do something similar.
quoted
quoted
+ pa |= FIELD_GET(KVM_PTE_ADDR_51_50, pte) << 50;
Where are bits 48 and 49?
Unlike the current FEAT_LPA feature, bits 48 and 49 are part of the PA
itself. Only the bits 50 and 51 move into bits 8 and 9, while creating
a PTE.
So why are you actively dropping these bits? Hint: look at
KVM_PTE_ADDR_MASK and the way it is used to extract the initial value
of 'pa'.
[...]
quoted hunk
quoted
Another thing I don't see is how you manage TLB invalidation by level
now that we gain a level 0 at 4kB, breaking the current assumptions
encoded in __tlbi_level().
Right, I guess something like this (not build tested) will be required as
level 0 for 4K and level 1 for 16K would only make sense when FEAT_LPA2 is
implemented, otherwise it will fallback to the default behaviour i.e table
level hint was not provided (TTL[3:2] is 0b00). Is there any other concern
which I might be missing here ?
@@ -104,8 +104,7 @@ static inline unsigned long get_trans_granule(void)#define __tlbi_level(op, addr, level) do { \u64arg=addr;\\-if(cpus_have_const_cap(ARM64_HAS_ARMv8_4_TTL)&&\-level){\+if(cpus_have_const_cap(ARM64_HAS_ARMv8_4_TTL){\u64ttl=level&3;\ttl|=get_trans_granule()<<2;\arg&=~TLBI_TTL_MASK;\
That's a start, but 0 has always meant 'at any level' until now. You
will have to audit all the call sites and work out whether they can
pass 0 if they don't track the actual level.
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Suzuki K Poulose <suzuki.poulose@arm.com> Date: 2021-10-12 10:41:52
On 30/09/2021 11:35, Anshuman Khandual wrote:
quoted hunk
FEAT_LPA2 requires different PTE representation formats for both 4K and 16K
page size config. This adds FEAT_LPA2 specific new PTE encodings as per ARM
ARM (0487G.A) which updates [pte|phys]_to_[phys|pte](). The updated helpers
would be used when FEAT_LPA2 gets enabled via CONFIG_ARM64_PA_BITS_52 on 4K
and 16K page size. Although TTBR encoding and phys_to_ttbr() helper remains
the same as FEAT_LPA for FEAT_LPA2 as well. It updates 'phys_to_pte' helper
to accept a temporary variable and changes impacted call sites.
Signed-off-by: Anshuman Khandual <redacted>
---
arch/arm64/include/asm/assembler.h | 14 +++++++++++---
arch/arm64/include/asm/pgtable-hwdef.h | 4 ++++
arch/arm64/include/asm/pgtable.h | 4 ++++
3 files changed, 19 insertions(+), 3 deletions(-)
nit: This looks like an unrelated change and is better suited for the previous patch.
Suzuki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
FEAT_LPA2 requires different PTE representation formats for both 4K and 16K
page size config. This adds FEAT_LPA2 specific new PTE encodings as per ARM
ARM (0487G.A) which updates [pte|phys]_to_[phys|pte](). The updated helpers
would be used when FEAT_LPA2 gets enabled via CONFIG_ARM64_PA_BITS_52 on 4K
and 16K page size. Although TTBR encoding and phys_to_ttbr() helper remains
the same as FEAT_LPA for FEAT_LPA2 as well. It updates 'phys_to_pte' helper
to accept a temporary variable and changes impacted call sites.
Signed-off-by: Anshuman Khandual <redacted>
---
arch/arm64/include/asm/assembler.h | 14 +++++++++++---
arch/arm64/include/asm/pgtable-hwdef.h | 4 ++++
arch/arm64/include/asm/pgtable.h | 4 ++++
3 files changed, 19 insertions(+), 3 deletions(-)
nit: This looks like an unrelated change and is better suited for the previous patch.
Changed the existing FEAT_LPA encodings here to use PAGE_SHIFT just
to match the new ones being added for FEAT_LPA2. But reasonable for
them to be folded into the previous patch instead.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Stage-2 FEAT_LPA2 support is independent and also orthogonal to FEAT_LPA2
support either in Stage-1 or in the host kernel. Stage-2 IPA range support
is evaluated from the platform via ID_AA64MMFR0_TGRAN_2_SUPPORTED_LPA2 and
gets enabled regardless of Stage-1 translation.
Signed-off-by: Anshuman Khandual <redacted>
---
arch/arm64/include/asm/kvm_pgtable.h | 10 +++++++++-
arch/arm64/kvm/hyp/pgtable.c | 25 +++++++++++++++++++++++--
arch/arm64/kvm/reset.c | 14 ++++++++++----
3 files changed, 42 insertions(+), 7 deletions(-)
Having to do a function call just for this test seems bad, specially
for something that is used so often on the fault path.
Why can't this be made a normal capability that indicates LPA support
for the current page size?
Although I could look into making this a normal capability check, would
not a static key based implementation be preferred if the function call
based construct here is too expensive ?
A capability *is* a static key. Specially if you make it final.
Sure.
quoted
Originally, avoided capability method for stage-2 because it would have
been difficult in stage-1 where the FEAT_LPA2 detection is required way
earlier during boot before cpu capability comes up. Hence just followed
a simple variable method both for stage-1 and stage-2 keeping it same.
I think you'll have to find a way to make it work with a capability
for S1 too. Capabilities can be used even when not final, and you may
have to do something similar.
Sure, will explore that.
quoted
quoted
quoted
+ pa |= FIELD_GET(KVM_PTE_ADDR_51_50, pte) << 50;
Where are bits 48 and 49?
Unlike the current FEAT_LPA feature, bits 48 and 49 are part of the PA
itself. Only the bits 50 and 51 move into bits 8 and 9, while creating
a PTE.
So why are you actively dropping these bits? Hint: look at
KVM_PTE_ADDR_MASK and the way it is used to extract the initial value
of 'pa'.
Right, will need another address mask i.e KVM_PTE_ADDR_MASK_50 which will
extract the PA field both in kvm_pte_to_phys() and kvm_phys_to_pte().
[...]
quoted
quoted
Another thing I don't see is how you manage TLB invalidation by level
now that we gain a level 0 at 4kB, breaking the current assumptions
encoded in __tlbi_level().
Right, I guess something like this (not build tested) will be required as
level 0 for 4K and level 1 for 16K would only make sense when FEAT_LPA2 is
implemented, otherwise it will fallback to the default behaviour i.e table
level hint was not provided (TTL[3:2] is 0b00). Is there any other concern
which I might be missing here ?
@@ -104,8 +104,7 @@ static inline unsigned long get_trans_granule(void)#define __tlbi_level(op, addr, level) do { \u64arg=addr;\\-if(cpus_have_const_cap(ARM64_HAS_ARMv8_4_TTL)&&\-level){\+if(cpus_have_const_cap(ARM64_HAS_ARMv8_4_TTL){\u64ttl=level&3;\ttl|=get_trans_granule()<<2;\arg&=~TLBI_TTL_MASK;\
That's a start, but 0 has always meant 'at any level' until now. You
will have to audit all the call sites and work out whether they can
pass 0 if they don't track the actual level.
Hmm, sure will audit the call sites. But wondering if the caller is not
sure about the level, should not it just use __tlbi(op, arg) instead ?
Seems like __tlbi_level(op, addr, level) should only accept level as 0
when the level is determined to be 0. The actual impact will depend on
if FEAT_LPA2 is implemented otherwise it falls back to __tlbi(op, arg).
Basically we should convert existing sites which call __tlbi_level()
with level as 0 (without determining), to use __tlbi() directly ?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel