From: Mark Rutland <mark.rutland@arm.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
Marc Zyngier <maz@kernel.org>, Will Deacon <will@kernel.org>,
Kees Cook <keescook@chromium.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Mark Brown <broonie@kernel.org>,
Anshuman Khandual <anshuman.khandual@arm.com>
Subject: Re: [PATCH v5 02/21] arm64: mm: make vabits_actual a build time constant if possible
Date: Sun, 26 Jun 2022 10:31:32 +0100 [thread overview]
Message-ID: <YrgndBReUXJhK/oY@FVFF77S0Q05N> (raw)
In-Reply-To: <20220624150651.1358849-3-ardb@kernel.org>
On Fri, Jun 24, 2022 at 05:06:32PM +0200, Ard Biesheuvel wrote:
> Currently, we only support 52-bit virtual addressing on 64k pages
> configurations, and in all other cases, vabits_actual is guaranteed to
> equal VA_BITS (== VA_BITS_MIN). So get rid of the variable entirely in
> that case.
>
> While at it, move the assignment out of the asm entry code - it has no
> need to be there.
>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
I see the patch itself checks VA_BITS rather than PAGE_SIZE, (and the former is
the right thing to for FEAT_LPA2), so FWIW:
Mark Rutland <mark.rutland@arm.com>
Mark.
> ---
> arch/arm64/include/asm/memory.h | 4 ++++
> arch/arm64/kernel/head.S | 15 +--------------
> arch/arm64/mm/init.c | 15 ++++++++++++++-
> arch/arm64/mm/mmu.c | 4 +++-
> 4 files changed, 22 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index 0af70d9abede..c751cd9b94f8 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -174,7 +174,11 @@
> #include <linux/types.h>
> #include <asm/bug.h>
>
> +#if VA_BITS > 48
> extern u64 vabits_actual;
> +#else
> +#define vabits_actual ((u64)VA_BITS)
> +#endif
>
> extern s64 memstart_addr;
> /* PHYS_OFFSET - the physical address of the start of memory. */
> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> index 1cdecce552bb..dc07858eb673 100644
> --- a/arch/arm64/kernel/head.S
> +++ b/arch/arm64/kernel/head.S
> @@ -293,19 +293,6 @@ SYM_FUNC_START_LOCAL(__create_page_tables)
> adrp x0, idmap_pg_dir
> adrp x3, __idmap_text_start // __pa(__idmap_text_start)
>
> -#ifdef CONFIG_ARM64_VA_BITS_52
> - mrs_s x6, SYS_ID_AA64MMFR2_EL1
> - and x6, x6, #(0xf << ID_AA64MMFR2_LVA_SHIFT)
> - mov x5, #52
> - cbnz x6, 1f
> -#endif
> - mov x5, #VA_BITS_MIN
> -1:
> - adr_l x6, vabits_actual
> - str x5, [x6]
> - dmb sy
> - dc ivac, x6 // Invalidate potentially stale cache line
> -
> /*
> * VA_BITS may be too small to allow for an ID mapping to be created
> * that covers system RAM if that is located sufficiently high in the
> @@ -713,7 +700,7 @@ SYM_FUNC_START(__enable_mmu)
> SYM_FUNC_END(__enable_mmu)
>
> SYM_FUNC_START(__cpu_secondary_check52bitva)
> -#ifdef CONFIG_ARM64_VA_BITS_52
> +#if VA_BITS > 48
> ldr_l x0, vabits_actual
> cmp x0, #52
> b.ne 2f
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 339ee84e5a61..1faa6760895e 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -265,7 +265,20 @@ early_param("mem", early_mem);
>
> void __init arm64_memblock_init(void)
> {
> - s64 linear_region_size = PAGE_END - _PAGE_OFFSET(vabits_actual);
> + s64 linear_region_size;
> +
> +#if VA_BITS > 48
> + if (cpuid_feature_extract_unsigned_field(
> + read_sysreg_s(SYS_ID_AA64MMFR2_EL1),
> + ID_AA64MMFR2_LVA_SHIFT))
> + vabits_actual = VA_BITS;
> +
> + /* make the variable visible to secondaries with the MMU off */
> + dcache_clean_inval_poc((u64)&vabits_actual,
> + (u64)&vabits_actual + sizeof(vabits_actual));
> +#endif
> +
> + linear_region_size = PAGE_END - _PAGE_OFFSET(vabits_actual);
>
> /*
> * Corner case: 52-bit VA capable systems running KVM in nVHE mode may
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 7148928e3932..a6392656d589 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -46,8 +46,10 @@
> u64 idmap_t0sz = TCR_T0SZ(VA_BITS_MIN);
> u64 idmap_ptrs_per_pgd = PTRS_PER_PGD;
>
> -u64 __section(".mmuoff.data.write") vabits_actual;
> +#if VA_BITS > 48
> +u64 vabits_actual __ro_after_init = VA_BITS_MIN;
> EXPORT_SYMBOL(vabits_actual);
> +#endif
>
> u64 kimage_vaddr __ro_after_init = (u64)&_text;
> EXPORT_SYMBOL(kimage_vaddr);
> --
> 2.35.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-06-26 9:32 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-24 15:06 [PATCH v5 00/21] arm64: refactor boot flow Ard Biesheuvel
2022-06-24 15:06 ` [PATCH v5 01/21] arm64: head: move kimage_vaddr variable into C file Ard Biesheuvel
2022-06-26 9:22 ` Mark Rutland
2022-06-24 15:06 ` [PATCH v5 02/21] arm64: mm: make vabits_actual a build time constant if possible Ard Biesheuvel
2022-06-26 9:31 ` Mark Rutland [this message]
2022-06-24 15:06 ` [PATCH v5 03/21] arm64: head: move assignment of idmap_t0sz to C code Ard Biesheuvel
2022-06-26 9:36 ` Mark Rutland
2022-06-24 15:06 ` [PATCH v5 04/21] arm64: head: drop idmap_ptrs_per_pgd Ard Biesheuvel
2022-06-26 9:37 ` Mark Rutland
2022-06-24 15:06 ` [PATCH v5 05/21] arm64: head: simplify page table mapping macros (slightly) Ard Biesheuvel
2022-06-26 10:07 ` Mark Rutland
2022-06-24 15:06 ` [PATCH v5 06/21] arm64: head: switch to map_memory macro for the extended ID map Ard Biesheuvel
2022-06-24 15:06 ` [PATCH v5 07/21] arm64: head: split off idmap creation code Ard Biesheuvel
2022-06-24 15:06 ` [PATCH v5 08/21] arm64: kernel: drop unnecessary PoC cache clean+invalidate Ard Biesheuvel
2022-06-24 15:06 ` [PATCH v5 09/21] arm64: head: pass ID map root table address to __enable_mmu() Ard Biesheuvel
2022-06-24 15:06 ` [PATCH v5 10/21] arm64: mm: provide idmap pointer to cpu_replace_ttbr1() Ard Biesheuvel
2022-06-24 15:06 ` [PATCH v5 11/21] arm64: head: add helper function to remap regions in early page tables Ard Biesheuvel
2022-06-24 15:06 ` [PATCH v5 12/21] arm64: head: cover entire kernel image in initial ID map Ard Biesheuvel
2022-06-24 15:06 ` [PATCH v5 13/21] arm64: head: use relative references to the RELA and RELR tables Ard Biesheuvel
2022-06-24 15:06 ` [PATCH v5 14/21] arm64: head: create a temporary FDT mapping in the initial ID map Ard Biesheuvel
2022-06-24 15:06 ` [PATCH v5 15/21] arm64: idreg-override: use early FDT mapping in " Ard Biesheuvel
2022-07-11 15:39 ` Mark Rutland
2022-07-12 17:03 ` Ard Biesheuvel
2022-07-13 14:09 ` Mark Rutland
2022-06-24 15:06 ` [PATCH v5 16/21] arm64: head: factor out TTBR1 assignment into a macro Ard Biesheuvel
2022-06-24 15:06 ` [PATCH v5 17/21] arm64: head: populate kernel page tables with MMU and caches on Ard Biesheuvel
2022-06-24 15:06 ` [PATCH v5 18/21] arm64: head: record CPU boot mode after enabling the MMU Ard Biesheuvel
2022-06-24 15:06 ` [PATCH v5 19/21] arm64: kaslr: defer initialization to initcall where permitted Ard Biesheuvel
2022-06-24 15:06 ` [PATCH v5 20/21] arm64: head: avoid relocating the kernel twice for KASLR Ard Biesheuvel
2022-06-24 15:06 ` [PATCH v5 21/21] arm64: setup: drop early FDT pointer helpers Ard Biesheuvel
2022-06-24 17:13 ` [PATCH v5 00/21] arm64: refactor boot flow Will Deacon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YrgndBReUXJhK/oY@FVFF77S0Q05N \
--to=mark.rutland@arm.com \
--cc=anshuman.khandual@arm.com \
--cc=ardb@kernel.org \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=keescook@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.