All of lore.kernel.org
 help / color / mirror / Atom feed
From: Usama Arif <usama.arif@linux.dev>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Usama Arif <usama.arif@linux.dev>,
	linux-arm-kernel@lists.infradead.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Ryan Roberts <ryan.roberts@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	David Hildenbrand <david@kernel.org>,
	Mike Rapoport <rppt@kernel.org>,
	Linu Cherian <linu.cherian@arm.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC V1 16/16] arm64/mm: Add initial support for FEAT_D128 page tables
Date: Thu, 26 Feb 2026 06:10:23 -0800	[thread overview]
Message-ID: <20260226141024.1869713-1-usama.arif@linux.dev> (raw)
In-Reply-To: <20260224051153.3150613-17-anshuman.khandual@arm.com>

On Tue, 24 Feb 2026 10:41:53 +0530 Anshuman Khandual <anshuman.khandual@arm.com> wrote:

> Add build time support for FEAT_D128 page tables with a new Kconfig option
> i.e CONFIG_ARM64_D128. When selected, PTE types become 128 bits wide and
> PTE bits are mapped to their new locations. Besides the basic page table
> geometry is also updated since each table page now holds half the number
> of entries (aka PTRS_PER_PXX) as it did previously.
> 
> Since FEAT_D128 exclusively supports the permission indirection style for
> page table entry permission management, given kernel compiled for FEAT_D128
> requires both FEAT_S1PIE and FEAT_D128. If these architecture features are
> not present at boot, the kernel panics just like it does when there is a
> granule size mismatch.
> 
> TTBR0/1_EL1 and PAR_EL1 registers become 128 bit wide when D128 is enabled,
> thus requiring MSRR/MRRS instructions for their updates. Because PA_BITS is
> still capped at 52 bits, MRS/MSR instructions are currently sufficient for
> the register accesses that basically operate on the lower 64 bits. Although
> entire 128 bits for these registers get cleared during boot via MSRR.
> 
> Add support for TLBIP instruction for TLB flush macros with level hint and
> address range operations. Although existing TLBI based TLB flush would have
> been sufficient given PA_BITS is still capped at 52, but then it would have
> lacked both level hint and range support.
> 
> This enables support for all granule size, VA_BITS and PA_BITS combination.
> 
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Ryan Roberts <ryan.roberts@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
>  arch/arm64/Kconfig                     |  39 ++++++-
>  arch/arm64/Makefile                    |   4 +
>  arch/arm64/include/asm/assembler.h     |   4 +-
>  arch/arm64/include/asm/el2_setup.h     |   9 ++
>  arch/arm64/include/asm/pgtable-hwdef.h | 137 +++++++++++++++++++++++++
>  arch/arm64/include/asm/pgtable-prot.h  |  18 +++-
>  arch/arm64/include/asm/pgtable-types.h |   9 ++
>  arch/arm64/include/asm/pgtable.h       |  56 +++++++++-
>  arch/arm64/include/asm/smp.h           |   1 +
>  arch/arm64/include/asm/tlbflush.h      |  65 ++++++++++++
>  arch/arm64/kernel/head.S               |  12 +++
>  arch/arm64/mm/proc.S                   |  25 ++++-
>  12 files changed, 372 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 38dba5f7e4d2..aaf910295c39 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -309,6 +309,10 @@ config GCC_SUPPORTS_DYNAMIC_FTRACE_WITH_ARGS
>  	def_bool CC_IS_GCC
>  	depends on $(cc-option,-fpatchable-function-entry=2)
>  
> +config CC_SUPPORTS_LSE128
> +	def_bool CC_IS_GCC
> +	depends on $(cc-option, -march=armv8.1-a+lse128)
> +
>  config 64BIT
>  	def_bool y
>  
> @@ -395,6 +399,16 @@ config FIX_EARLYCON_MEM
>  
>  config PGTABLE_LEVELS
>  	int
> +	default 4 if ARM64_D128 && ARM64_4K_PAGES && ARM64_VA_BITS_39
> +	default 5 if ARM64_D128 && ARM64_4K_PAGES && ARM64_VA_BITS_48
> +	default 5 if ARM64_D128 && ARM64_4K_PAGES && ARM64_VA_BITS_52
> +	default 3 if ARM64_D128 && ARM64_16K_PAGES && ARM64_VA_BITS_36
> +	default 4 if ARM64_D128 && ARM64_16K_PAGES && ARM64_VA_BITS_47
> +	default 4 if ARM64_D128 && ARM64_16K_PAGES && ARM64_VA_BITS_48
> +	default 4 if ARM64_D128 && ARM64_16K_PAGES && ARM64_VA_BITS_52
> +	default 3 if ARM64_D128 && ARM64_64K_PAGES && ARM64_VA_BITS_42
> +	default 3 if ARM64_D128 && ARM64_64K_PAGES && ARM64_VA_BITS_48
> +	default 3 if ARM64_D128 && ARM64_64K_PAGES && ARM64_VA_BITS_52
>  	default 2 if ARM64_16K_PAGES && ARM64_VA_BITS_36
>  	default 2 if ARM64_64K_PAGES && ARM64_VA_BITS_42
>  	default 3 if ARM64_64K_PAGES && (ARM64_VA_BITS_48 || ARM64_VA_BITS_52)
> @@ -1504,7 +1518,7 @@ config ARM64_PA_BITS
>  
>  config ARM64_LPA2
>  	def_bool y
> -	depends on ARM64_PA_BITS_52 && !ARM64_64K_PAGES
> +	depends on ARM64_PA_BITS_52 && !ARM64_64K_PAGES && !ARM64_D128
>  
>  choice
>  	prompt "Endianness"
> @@ -2195,6 +2209,29 @@ config ARM64_HAFT
>  
>  endmenu # "ARMv8.9 architectural features"
>  
> +menu "ARMv9.3 architectural features"
> +
> +config AS_HAS_ARMV9_3
> +	def_bool $(cc-option,-Wa$(comma)-march=armv9.3-a)
> +
> +config ARM64_D128
> +	bool "Enable support for 128 bit page table (FEAT_D128)"
> +	depends on ARCH_SUPPORTS_INT128
> +	depends on CC_SUPPORTS_LSE128
> +	depends on AS_HAS_ARMV9_3
> +	depends on EXPERT
> +	depends on !VIRTUALIZATION
> +	depends on !KASAN
> +	depends on !UNMAP_KERNEL_AT_EL0
> +	default n
> +	help
> +	  ARMv9.3 introduces FEAT_D128, which provides a 128 bit page
> +	  table format, along with related instructions.
> +
> +	  If unsure, say Y.
> +

Should this say, If unsure, say N?

> +endmenu # "ARMv9.3 architectural features"
> +

[...]

> diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
> index 9c93ffbcc1e0..a221a1a9b87e 100644
> --- a/arch/arm64/include/asm/tlbflush.h
> +++ b/arch/arm64/include/asm/tlbflush.h
> @@ -49,6 +49,19 @@
>  
>  #define __tlbi(op, ...)		__TLBI_N(op, ##__VA_ARGS__, 1, 0)
>  
> +#ifdef CONFIG_ARM64_D128
> +#define __tlbip(op, arg1, arg2) do {	\
> +	u128 value = 0;			\
> +	value |= (u128)arg2 << 64;	\
> +	value |= (u128)arg1;		\
> +					\
> +	asm (ARM64_ASM_PREAMBLE		\
> +	".arch_extension d128\n\t"	\
> +	"tlbip " #op ", %0, %H0\n"	\
> +	: : "r" (value));		\
> +} while (0)
> +#endif
> +
>  #define __tlbi_user(op, arg) do {						\
>  	if (arm64_kernel_unmapped_at_el0())					\
>  		__tlbi(op, (arg) | USER_ASID_FLAG);				\
> @@ -128,6 +141,46 @@ static inline unsigned long get_trans_granule(void)
>  		__tlbi_level(op, (arg | USER_ASID_FLAG), level);	\
>  } while (0)
>  
> +#ifdef CONFIG_ARM64_D128
> +/*
> + *
> + * TLBIP Encoding
> + *
> + * +------------+-----------------+-------+-------+------------------+
> + * |     RES0   |     BADDR       |  ASID |  TTL  |      RES0        |
> + * +------------------------------+-------+-------+------------------+
> + * |127      108|107            64|63   48|47   44|43               0|
> + */
> +
> +#define __tlbip_user(op, arg, addr) do {					\
> +	if (arm64_kernel_unmapped_at_el0())					\
> +		__tlbip(op, (arg) | USER_ASID_FLAG, addr);			\
> +} while (0)
> +/*
> + * FEAT_TTL being mandatory from armv8.4 and FEAT_D128 is available
> + * only from armv9.4, we dont need the capability check for TTL.
> + */
> +#define __TLBIP_ARGS(asid, level)						\
> +	({									\
> +		u64 arg = 0;							\
> +										\
> +		arg |= FIELD_PREP(TLBI_ASID_MASK, (asid));			\
> +		if ((level) >= 0 && (level) <= 3) {				\
> +			arg |= FIELD_PREP(TLBI_TG_MASK, get_trans_granule());	\
> +			arg |= FIELD_PREP(TLBI_LVL_MASK, (level));		\
> +		}								\
> +		arg;								\
> +	})									\
> +
> +#define __tlb_asid_level(op, addr, asid, level, tlb_user) do {		\
> +	u64 arg1 = __TLBIP_ARGS(asid, level);				\
> +	u64 arg2 = (addr) >> 12;					\

Does 12 over here represent PAGE_SHIFT? If so, would it break 16K and 64K PAGE_SIZE?

> +									\
> +	__tlbip(op, arg1, arg2);					\
> +	if (tlb_user)							\
> +		__tlbip_user(op, arg1, arg2);				\
> +} while (0)
> +#else
>  #define __tlb_asid_level(op, addr, asid, level, tlb_user) do {		\
>  	u64 arg1;							\
>  									\










































































































  reply	other threads:[~2026-02-26 14:10 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-24  5:11 [RFC V1 00/16] arm64/mm: Enable 128 bit page table entries Anshuman Khandual
2026-02-24  5:11 ` [RFC V1 01/16] mm: Abstract printing of pxd_val() Anshuman Khandual
2026-02-26 12:34   ` Usama Arif
2026-02-26 12:49     ` Anshuman Khandual
2026-04-09 10:33   ` Mike Rapoport
2026-04-10  4:21     ` Anshuman Khandual
2026-02-24  5:11 ` [RFC V1 02/16] mm: Add read-write accessors for vm_page_prot Anshuman Khandual
2026-04-09 10:37   ` Mike Rapoport
2026-04-10  4:29     ` Anshuman Khandual
2026-02-24  5:11 ` [RFC V1 03/16] mm: Replace READ_ONCE() in pud_trans_unstable() Anshuman Khandual
2026-02-24  5:11 ` [RFC V1 04/16] perf/events: Replace READ_ONCE() with standard pgtable accessors Anshuman Khandual
2026-02-24  8:48   ` Peter Zijlstra
2026-02-24 10:08   ` Mark Rutland
2026-02-24 10:41     ` Peter Zijlstra
2026-02-24 11:22       ` Ryan Roberts
2026-02-24 12:49         ` Anshuman Khandual
2026-02-24 12:39       ` Anshuman Khandual
2026-02-24 12:53     ` Anshuman Khandual
2026-02-24  5:11 ` [RFC V1 05/16] arm64/mm: Convert READ_ONCE() as pmdp_get() while accessing PMD Anshuman Khandual
2026-04-08 12:11   ` David Hildenbrand (Arm)
2026-04-10  4:48     ` Anshuman Khandual
2026-04-15 10:31       ` David Hildenbrand (Arm)
2026-02-24  5:11 ` [RFC V1 06/16] arm64/mm: Convert READ_ONCE() as pudp_get() while accessing PUD Anshuman Khandual
2026-04-08 12:15   ` David Hildenbrand (Arm)
2026-04-10  4:50     ` Anshuman Khandual
2026-04-15 10:32       ` David Hildenbrand (Arm)
2026-02-24  5:11 ` [RFC V1 07/16] arm64/mm: Convert READ_ONCE() as p4dp_get() while accessing P4D Anshuman Khandual
2026-02-24  7:09   ` kernel test robot
2026-04-08 12:17   ` David Hildenbrand (Arm)
2026-04-10  5:05     ` Anshuman Khandual
2026-04-15 10:35       ` David Hildenbrand (Arm)
2026-02-24  5:11 ` [RFC V1 08/16] arm64/mm: Convert READ_ONCE() as pgdp_get() while accessing PGD Anshuman Khandual
2026-02-24  8:31   ` kernel test robot
2026-04-08 12:19   ` David Hildenbrand (Arm)
2026-04-10  5:30     ` Anshuman Khandual
2026-04-15 10:37       ` David Hildenbrand (Arm)
2026-02-24  5:11 ` [RFC V1 09/16] arm64/mm: Route all pgtable reads via ptdesc_get() Anshuman Khandual
2026-02-28 11:17   ` Mike Rapoport
2026-03-02  4:34     ` Anshuman Khandual
2026-04-08 12:25       ` David Hildenbrand (Arm)
2026-02-24  5:11 ` [RFC V1 10/16] arm64/mm: Route all pgtable writes via ptdesc_set() Anshuman Khandual
2026-02-26 12:37   ` Usama Arif
2026-02-26 12:54     ` Anshuman Khandual
2026-02-26 13:19       ` Ryan Roberts
2026-02-27  6:19         ` Anshuman Khandual
2026-02-24  5:11 ` [RFC V1 11/16] arm64/mm: Route all pgtable atomics to central helpers Anshuman Khandual
2026-04-08 12:28   ` David Hildenbrand (Arm)
2026-04-10  4:02     ` Anshuman Khandual
2026-04-15 10:38       ` David Hildenbrand (Arm)
2026-02-24  5:11 ` [RFC V1 12/16] arm64/mm: Abstract printing of pxd_val() Anshuman Khandual
2026-04-08 12:28   ` David Hildenbrand (Arm)
2026-04-10  4:05     ` Anshuman Khandual
2026-02-24  5:11 ` [RFC V1 13/16] arm64/mm: Override read-write accessors for vm_page_prot Anshuman Khandual
2026-02-24  5:11 ` [RFC V1 14/16] arm64/mm: Enable fixmap with 5 level page table Anshuman Khandual
2026-04-08 12:29   ` David Hildenbrand (Arm)
2026-04-10  3:22     ` Anshuman Khandual
2026-04-15 10:39       ` David Hildenbrand (Arm)
2026-02-24  5:11 ` [RFC V1 15/16] arm64/mm: Add macros __tlb_asid_level and __tlb_range Anshuman Khandual
2026-02-24  5:11 ` [RFC V1 16/16] arm64/mm: Add initial support for FEAT_D128 page tables Anshuman Khandual
2026-02-26 14:10   ` Usama Arif [this message]
2026-04-07 14:44 ` [RFC V1 00/16] arm64/mm: Enable 128 bit page table entries David Hildenbrand (Arm)
2026-04-08 10:53   ` Anshuman Khandual
2026-04-08 11:01     ` Ryan Roberts
2026-04-08 12:13     ` David Hildenbrand (Arm)
2026-04-09  2:08       ` Anshuman Khandual

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=20260226141024.1869713-1-usama.arif@linux.dev \
    --to=usama.arif@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=anshuman.khandual@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=david@kernel.org \
    --cc=linu.cherian@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=mark.rutland@arm.com \
    --cc=rppt@kernel.org \
    --cc=ryan.roberts@arm.com \
    --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.