[PATCH v3 0/3] support FEAT_MTE_TAGGED_FAR feature

[PATCH v3 0/3] support FEAT_MTE_TAGGED_FAR feature

[Yeoreum Yun]

The FEAT_MTE_TAGGED_FAR feature provides support for
reporting all non-address bits during a synchronous MTE tag check fault.

This patchset extends the reporting tag to include
not only the memory tag (logical tag) but also the address tag via
si_addr when FEAT_MTE_TAGGED_FAR feature is supported.

Since v1:
  - add hwcap test for MTE_FAR feature.
  - add MTE_FAR doc into elf_hwcap.rst

Since v2:
  - Rebase to 6.15-rc1

Yeoreum Yun (3):
  arm64: add FEAT_MTE_TAGGED_FAR feature
  arm64/mm/fault: use original FAR_EL1 value when ARM64_MTE_FAR is
    supported
  tools/kselftest: add MTE_FAR hwcap test

 Documentation/arch/arm64/elf_hwcaps.rst      |  3 +++
 Documentation/arch/arm64/tagged-pointers.rst | 11 ++++++-----
 arch/arm64/include/asm/hwcap.h               |  1 +
 arch/arm64/include/uapi/asm/hwcap.h          |  1 +
 arch/arm64/kernel/cpufeature.c               |  9 +++++++++
 arch/arm64/kernel/cpuinfo.c                  |  1 +
 arch/arm64/mm/fault.c                        |  7 +++++--
 arch/arm64/tools/cpucaps                     |  1 +
 tools/testing/selftests/arm64/abi/hwcap.c    |  6 ++++++
 9 files changed, 33 insertions(+), 7 deletions(-)

--
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}

[PATCH v3 1/3] arm64: add FEAT_MTE_TAGGED_FAR feature

[Yeoreum Yun]

Add FEAT_MTE_TAGGED_FAR cpucap which makes FAR_ELx report
all non-address bits on a synchronous MTE tag check fault since Armv8.9

Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
Acked-by: Yury Khrustalev <yury.khrustalev@arm.com>
---
 Documentation/arch/arm64/elf_hwcaps.rst      |  3 +++
 Documentation/arch/arm64/tagged-pointers.rst | 11 ++++++-----
 arch/arm64/include/asm/hwcap.h               |  1 +
 arch/arm64/include/uapi/asm/hwcap.h          |  1 +
 arch/arm64/kernel/cpufeature.c               |  9 +++++++++
 arch/arm64/kernel/cpuinfo.c                  |  1 +
 arch/arm64/tools/cpucaps                     |  1 +
 7 files changed, 22 insertions(+), 5 deletions(-)

diff --git a/Documentation/arch/arm64/elf_hwcaps.rst b/Documentation/arch/arm64/elf_hwcaps.rst
index 69d7afe56853..358f5af035ff 100644
--- a/Documentation/arch/arm64/elf_hwcaps.rst
+++ b/Documentation/arch/arm64/elf_hwcaps.rst
@@ -435,6 +435,9 @@ HWCAP2_SME_SF8DP4
 HWCAP2_POE
     Functionality implied by ID_AA64MMFR3_EL1.S1POE == 0b0001.

+HWCAP3_MTE_FAR
+    Functionality implied by ID_AA64PFR2_EL1.MTEFAR == 0b0001.
+
 4. Unused AT_HWCAP bits
 -----------------------

diff --git a/Documentation/arch/arm64/tagged-pointers.rst b/Documentation/arch/arm64/tagged-pointers.rst
index 81b6c2a770dd..73c59a9c7a63 100644
--- a/Documentation/arch/arm64/tagged-pointers.rst
+++ b/Documentation/arch/arm64/tagged-pointers.rst
@@ -60,11 +60,12 @@ that signal handlers in applications making use of tags cannot rely
 on the tag information for user virtual addresses being maintained
 in these fields unless the flag was set.

-Due to architecture limitations, bits 63:60 of the fault address
-are not preserved in response to synchronous tag check faults
-(SEGV_MTESERR) even if SA_EXPOSE_TAGBITS was set. Applications should
-treat the values of these bits as undefined in order to accommodate
-future architecture revisions which may preserve the bits.
+If FEAT_MTE_TAGGED_FAR (Armv8.9) is supported, bits 63:60 of the fault address
+are preserved in response to synchronous tag check faults (SEGV_MTESERR)
+otherwise not preserved even if SA_EXPOSE_TAGBITS was set.
+Applications should interpret the values of these bits based on
+the support for the 'mte_far' hwcap. If the support is not present,
+the values of these bits should be considered as undefined otherwise valid.

 For signals raised in response to watchpoint debug exceptions, the
 tag information will be preserved regardless of the SA_EXPOSE_TAGBITS
diff --git a/arch/arm64/include/asm/hwcap.h b/arch/arm64/include/asm/hwcap.h
index 1c3f9617d54f..28dd1ac29ecc 100644
--- a/arch/arm64/include/asm/hwcap.h
+++ b/arch/arm64/include/asm/hwcap.h
@@ -176,6 +176,7 @@
 #define KERNEL_HWCAP_POE		__khwcap2_feature(POE)

 #define __khwcap3_feature(x)		(const_ilog2(HWCAP3_ ## x) + 128)
+#define KERNEL_HWCAP_MTE_FAR		__khwcap3_feature(MTE_FAR)

 /*
  * This yields a mask that user programs can use to figure out what
diff --git a/arch/arm64/include/uapi/asm/hwcap.h b/arch/arm64/include/uapi/asm/hwcap.h
index 705a7afa8e58..7d22527a7975 100644
--- a/arch/arm64/include/uapi/asm/hwcap.h
+++ b/arch/arm64/include/uapi/asm/hwcap.h
@@ -143,5 +143,6 @@
 /*
  * HWCAP3 flags - for AT_HWCAP3
  */
+#define HWCAP3_MTE_FAR		(1UL << 0)

 #endif /* _UAPI__ASM_HWCAP_H */
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 9c4d6d552b25..183b4b7e3074 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -312,6 +312,7 @@ static const struct arm64_ftr_bits ftr_id_aa64pfr1[] = {

 static const struct arm64_ftr_bits ftr_id_aa64pfr2[] = {
 	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR2_EL1_FPMR_SHIFT, 4, 0),
+	ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR2_EL1_MTEFAR_SHIFT, 4, ID_AA64PFR2_EL1_MTEFAR_NI),
 	ARM64_FTR_END,
 };

@@ -2861,6 +2862,13 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
 		.matches = has_cpuid_feature,
 		ARM64_CPUID_FIELDS(ID_AA64PFR1_EL1, MTE, MTE3)
 	},
+	{
+		.desc = "FAR on MTE Tag Check Fault",
+		.capability = ARM64_MTE_FAR,
+		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
+		.matches = has_cpuid_feature,
+		ARM64_CPUID_FIELDS(ID_AA64PFR2_EL1, MTEFAR, IMP)
+	},
 #endif /* CONFIG_ARM64_MTE */
 	{
 		.desc = "RCpc load-acquire (LDAPR)",
@@ -3191,6 +3199,7 @@ static const struct arm64_cpu_capabilities arm64_elf_hwcaps[] = {
 #ifdef CONFIG_ARM64_MTE
 	HWCAP_CAP(ID_AA64PFR1_EL1, MTE, MTE2, CAP_HWCAP, KERNEL_HWCAP_MTE),
 	HWCAP_CAP(ID_AA64PFR1_EL1, MTE, MTE3, CAP_HWCAP, KERNEL_HWCAP_MTE3),
+	HWCAP_CAP(ID_AA64PFR2_EL1, MTEFAR, IMP, CAP_HWCAP, KERNEL_HWCAP_MTE_FAR),
 #endif /* CONFIG_ARM64_MTE */
 	HWCAP_CAP(ID_AA64MMFR0_EL1, ECV, IMP, CAP_HWCAP, KERNEL_HWCAP_ECV),
 	HWCAP_CAP(ID_AA64MMFR1_EL1, AFP, IMP, CAP_HWCAP, KERNEL_HWCAP_AFP),
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 285d7d538342..e2b13454e38a 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -160,6 +160,7 @@ static const char *const hwcap_str[] = {
 	[KERNEL_HWCAP_SME_SFEXPA]	= "smesfexpa",
 	[KERNEL_HWCAP_SME_STMOP]	= "smestmop",
 	[KERNEL_HWCAP_SME_SMOP4]	= "smesmop4",
+	[KERNEL_HWCAP_MTE_FAR]		= "mte_far",
 };

 #ifdef CONFIG_COMPAT
diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
index 772c1b008e43..ef62ea04ba37 100644
--- a/arch/arm64/tools/cpucaps
+++ b/arch/arm64/tools/cpucaps
@@ -67,6 +67,7 @@ MPAM
 MPAM_HCR
 MTE
 MTE_ASYMM
+MTE_FAR
 SME
 SME_FA64
 SME2
--
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}

Re: [PATCH v3 1/3] arm64: add FEAT_MTE_TAGGED_FAR feature

[Catalin Marinas]

On Thu, Apr 10, 2025 at 08:47:19AM +0100, Yeoreum Yun wrote:
> Add FEAT_MTE_TAGGED_FAR cpucap which makes FAR_ELx report
> all non-address bits on a synchronous MTE tag check fault since Armv8.9
> 
> Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> Acked-by: Yury Khrustalev <yury.khrustalev@arm.com>
[...]
> @@ -3191,6 +3199,7 @@ static const struct arm64_cpu_capabilities arm64_elf_hwcaps[] = {
>  #ifdef CONFIG_ARM64_MTE
>  	HWCAP_CAP(ID_AA64PFR1_EL1, MTE, MTE2, CAP_HWCAP, KERNEL_HWCAP_MTE),
>  	HWCAP_CAP(ID_AA64PFR1_EL1, MTE, MTE3, CAP_HWCAP, KERNEL_HWCAP_MTE3),
> +	HWCAP_CAP(ID_AA64PFR2_EL1, MTEFAR, IMP, CAP_HWCAP, KERNEL_HWCAP_MTE_FAR),

Nitpick: from a theoretical bisectability perspective, I'd move the
hwcap exposing to the following patch. The rest, feature detection etc
can stay in this file. Otherwise, one can apply this patch, see the
hwcap but not get the actual behaviour.

>  #endif /* CONFIG_ARM64_MTE */
>  	HWCAP_CAP(ID_AA64MMFR0_EL1, ECV, IMP, CAP_HWCAP, KERNEL_HWCAP_ECV),
>  	HWCAP_CAP(ID_AA64MMFR1_EL1, AFP, IMP, CAP_HWCAP, KERNEL_HWCAP_AFP),
> diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
> index 285d7d538342..e2b13454e38a 100644
> --- a/arch/arm64/kernel/cpuinfo.c
> +++ b/arch/arm64/kernel/cpuinfo.c
> @@ -160,6 +160,7 @@ static const char *const hwcap_str[] = {
>  	[KERNEL_HWCAP_SME_SFEXPA]	= "smesfexpa",
>  	[KERNEL_HWCAP_SME_STMOP]	= "smestmop",
>  	[KERNEL_HWCAP_SME_SMOP4]	= "smesmop4",
> +	[KERNEL_HWCAP_MTE_FAR]		= "mte_far",

Personal preference: "mtefar" (no underscore), mostly because there's no
other underscore in the hwcap strings yet ;).

-- 
Catalin

Re: [PATCH v3 1/3] arm64: add FEAT_MTE_TAGGED_FAR feature

[Yeoreum Yun]

Hi Catalin,

> On Thu, Apr 10, 2025 at 08:47:19AM +0100, Yeoreum Yun wrote:
> > Add FEAT_MTE_TAGGED_FAR cpucap which makes FAR_ELx report
> > all non-address bits on a synchronous MTE tag check fault since Armv8.9
> >
> > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > Acked-by: Yury Khrustalev <yury.khrustalev@arm.com>
> [...]
> > @@ -3191,6 +3199,7 @@ static const struct arm64_cpu_capabilities arm64_elf_hwcaps[] = {
> >  #ifdef CONFIG_ARM64_MTE
> >  	HWCAP_CAP(ID_AA64PFR1_EL1, MTE, MTE2, CAP_HWCAP, KERNEL_HWCAP_MTE),
> >  	HWCAP_CAP(ID_AA64PFR1_EL1, MTE, MTE3, CAP_HWCAP, KERNEL_HWCAP_MTE3),
> > +	HWCAP_CAP(ID_AA64PFR2_EL1, MTEFAR, IMP, CAP_HWCAP, KERNEL_HWCAP_MTE_FAR),
>
> Nitpick: from a theoretical bisectability perspective, I'd move the
> hwcap exposing to the following patch. The rest, feature detection etc
> can stay in this file. Otherwise, one can apply this patch, see the
> hwcap but not get the actual behaviour.

Thanks. I'll squash realted HWCAP to followin patch.

> >  #endif /* CONFIG_ARM64_MTE */
> >  	HWCAP_CAP(ID_AA64MMFR0_EL1, ECV, IMP, CAP_HWCAP, KERNEL_HWCAP_ECV),
> >  	HWCAP_CAP(ID_AA64MMFR1_EL1, AFP, IMP, CAP_HWCAP, KERNEL_HWCAP_AFP),
> > diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
> > index 285d7d538342..e2b13454e38a 100644
> > --- a/arch/arm64/kernel/cpuinfo.c
> > +++ b/arch/arm64/kernel/cpuinfo.c
> > @@ -160,6 +160,7 @@ static const char *const hwcap_str[] = {
> >  	[KERNEL_HWCAP_SME_SFEXPA]	= "smesfexpa",
> >  	[KERNEL_HWCAP_SME_STMOP]	= "smestmop",
> >  	[KERNEL_HWCAP_SME_SMOP4]	= "smesmop4",
> > +	[KERNEL_HWCAP_MTE_FAR]		= "mte_far",
>
> Personal preference: "mtefar" (no underscore), mostly because there's no
> other underscore in the hwcap strings yet ;).

Thanks. I'll change it!

--
Sincerely,
Yeoreum Yun

[PATCH v3 2/3] arm64/mm/fault: use original FAR_EL1 value when ARM64_MTE_FAR is supported

[Yeoreum Yun]

Use the original FAR_EL1 value when an MTE tag check fault occurs,
if ARM64_MTE_FAR is supported.
This allows reports to include not only the logical tag (memory tag)
but also the address tag information.

Applications that require this information should install a signal handler with
the SA_EXPOSE_TAGBITS flag.
While this introduces a minor ABI change,
most applications do not set this flag and therefore will not be affected.

Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
---
 arch/arm64/mm/fault.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index ec0a337891dd..f21d972f99b1 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -837,9 +837,12 @@ static int do_tag_check_fault(unsigned long far, unsigned long esr,
 	/*
 	 * The architecture specifies that bits 63:60 of FAR_EL1 are UNKNOWN
 	 * for tag check faults. Set them to corresponding bits in the untagged
-	 * address.
+	 * address if ARM64_MTE_FAR isn't supported.
+	 * Otherwise, bits 63:60 of FAR_EL1 are KNOWN.
 	 */
-	far = (__untagged_addr(far) & ~MTE_TAG_MASK) | (far & MTE_TAG_MASK);
+	if (!cpus_have_cap(ARM64_MTE_FAR))
+		far = (__untagged_addr(far) & ~MTE_TAG_MASK) | (far & MTE_TAG_MASK);
+
 	do_bad_area(far, esr, regs);
 	return 0;
 }
-- 
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}

Re: [PATCH v3 2/3] arm64/mm/fault: use original FAR_EL1 value when ARM64_MTE_FAR is supported

[Catalin Marinas]

+ Peter Collingbourne as he added the SA_EXPOSE_TAGBITS flag.

On Thu, Apr 10, 2025 at 08:47:20AM +0100, Yeoreum Yun wrote:
> Use the original FAR_EL1 value when an MTE tag check fault occurs,
> if ARM64_MTE_FAR is supported.
> This allows reports to include not only the logical tag (memory tag)
> but also the address tag information.
> 
> Applications that require this information should install a signal handler with
> the SA_EXPOSE_TAGBITS flag.
> While this introduces a minor ABI change,
> most applications do not set this flag and therefore will not be affected.

It is indeed a minor ABI in that a tag check fault resulting in a
signal will report the bits 63:60 as well, not just 59:56 of the address
(if the signal handler was registered with SA_EXPOSE_TAGBITS).

I don't think user-space would notice but asking Peter.

> Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> ---
>  arch/arm64/mm/fault.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> index ec0a337891dd..f21d972f99b1 100644
> --- a/arch/arm64/mm/fault.c
> +++ b/arch/arm64/mm/fault.c
> @@ -837,9 +837,12 @@ static int do_tag_check_fault(unsigned long far, unsigned long esr,
>  	/*
>  	 * The architecture specifies that bits 63:60 of FAR_EL1 are UNKNOWN
>  	 * for tag check faults. Set them to corresponding bits in the untagged
> -	 * address.
> +	 * address if ARM64_MTE_FAR isn't supported.
> +	 * Otherwise, bits 63:60 of FAR_EL1 are KNOWN.
>  	 */
> -	far = (__untagged_addr(far) & ~MTE_TAG_MASK) | (far & MTE_TAG_MASK);
> +	if (!cpus_have_cap(ARM64_MTE_FAR))
> +		far = (__untagged_addr(far) & ~MTE_TAG_MASK) | (far & MTE_TAG_MASK);
> +
>  	do_bad_area(far, esr, regs);
>  	return 0;
>  }
> -- 
> LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}

Re: [PATCH v3 2/3] arm64/mm/fault: use original FAR_EL1 value when ARM64_MTE_FAR is supported

[Peter Collingbourne]

On Fri, May 2, 2025 at 10:08 AM Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> + Peter Collingbourne as he added the SA_EXPOSE_TAGBITS flag.
>
> On Thu, Apr 10, 2025 at 08:47:20AM +0100, Yeoreum Yun wrote:
> > Use the original FAR_EL1 value when an MTE tag check fault occurs,
> > if ARM64_MTE_FAR is supported.
> > This allows reports to include not only the logical tag (memory tag)
> > but also the address tag information.
> >
> > Applications that require this information should install a signal handler with
> > the SA_EXPOSE_TAGBITS flag.
> > While this introduces a minor ABI change,
> > most applications do not set this flag and therefore will not be affected.
>
> It is indeed a minor ABI in that a tag check fault resulting in a
> signal will report the bits 63:60 as well, not just 59:56 of the address
> (if the signal handler was registered with SA_EXPOSE_TAGBITS).
>
> I don't think user-space would notice but asking Peter.

On Android we don't set bits 63:60 on heap addresses when MTE is
enabled (and userspace programs aren't allowed to modify them in
addresses they get back from the heap allocator either) so the fault
handler should continue to see them as 0. Of course, a userspace
program could be breaking the rules and setting those bits anyway, but
in that case it looks like the only consequence would be that the
error reports from the heap allocator would sometimes be missing some
information (and this could already happen if the access results in a
non-MTE fault) which I think is acceptable.

Peter

>
> > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > ---
> >  arch/arm64/mm/fault.c | 7 +++++--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> > index ec0a337891dd..f21d972f99b1 100644
> > --- a/arch/arm64/mm/fault.c
> > +++ b/arch/arm64/mm/fault.c
> > @@ -837,9 +837,12 @@ static int do_tag_check_fault(unsigned long far, unsigned long esr,
> >       /*
> >        * The architecture specifies that bits 63:60 of FAR_EL1 are UNKNOWN
> >        * for tag check faults. Set them to corresponding bits in the untagged
> > -      * address.
> > +      * address if ARM64_MTE_FAR isn't supported.
> > +      * Otherwise, bits 63:60 of FAR_EL1 are KNOWN.
> >        */
> > -     far = (__untagged_addr(far) & ~MTE_TAG_MASK) | (far & MTE_TAG_MASK);
> > +     if (!cpus_have_cap(ARM64_MTE_FAR))
> > +             far = (__untagged_addr(far) & ~MTE_TAG_MASK) | (far & MTE_TAG_MASK);
> > +
> >       do_bad_area(far, esr, regs);
> >       return 0;
> >  }
> > --
> > LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}

Re: [PATCH v3 2/3] arm64/mm/fault: use original FAR_EL1 value when ARM64_MTE_FAR is supported

[Yeoreum Yun]

Hi Peter,

> On Fri, May 2, 2025 at 10:08 AM Catalin Marinas <catalin.marinas@arm.com> wrote:
> >
> > + Peter Collingbourne as he added the SA_EXPOSE_TAGBITS flag.
> >
> > On Thu, Apr 10, 2025 at 08:47:20AM +0100, Yeoreum Yun wrote:
> > > Use the original FAR_EL1 value when an MTE tag check fault occurs,
> > > if ARM64_MTE_FAR is supported.
> > > This allows reports to include not only the logical tag (memory tag)
> > > but also the address tag information.
> > >
> > > Applications that require this information should install a signal handler with
> > > the SA_EXPOSE_TAGBITS flag.
> > > While this introduces a minor ABI change,
> > > most applications do not set this flag and therefore will not be affected.
> >
> > It is indeed a minor ABI in that a tag check fault resulting in a
> > signal will report the bits 63:60 as well, not just 59:56 of the address
> > (if the signal handler was registered with SA_EXPOSE_TAGBITS).
> >
> > I don't think user-space would notice but asking Peter.
>
> On Android we don't set bits 63:60 on heap addresses when MTE is
> enabled (and userspace programs aren't allowed to modify them in
> addresses they get back from the heap allocator either) so the fault
> handler should continue to see them as 0. Of course, a userspace
> program could be breaking the rules and setting those bits anyway, but
> in that case it looks like the only consequence would be that the
> error reports from the heap allocator would sometimes be missing some
> information (and this could already happen if the access results in a
> non-MTE fault) which I think is acceptable.
>
> Peter

Thanks for your confirmation :)

--
Sincerely,
Yeoreum Yun

[PATCH v3 3/3] tools/kselftest: add MTE_FAR hwcap test

[Yeoreum Yun]

add MTE_FAR hwcap test on kselftest.

Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
---
 tools/testing/selftests/arm64/abi/hwcap.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/tools/testing/selftests/arm64/abi/hwcap.c b/tools/testing/selftests/arm64/abi/hwcap.c
index 35f521e5f41c..a539eeb0bfc0 100644
--- a/tools/testing/selftests/arm64/abi/hwcap.c
+++ b/tools/testing/selftests/arm64/abi/hwcap.c
@@ -1098,6 +1098,12 @@ static const struct hwcap_data {
 		.sigill_fn = hbc_sigill,
 		.sigill_reliable = true,
 	},
+	{
+		.name = "MTE_FAR",
+		.at_hwcap = AT_HWCAP3,
+		.hwcap_bit = HWCAP3_MTE_FAR,
+		.cpuinfo = "mte_far",
+	},
 };

 typedef void (*sighandler_fn)(int, siginfo_t *, void *);
--
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}

Re: [PATCH v3 3/3] tools/kselftest: add MTE_FAR hwcap test

[Catalin Marinas]

On Thu, Apr 10, 2025 at 08:47:21AM +0100, Yeoreum Yun wrote:
> diff --git a/tools/testing/selftests/arm64/abi/hwcap.c b/tools/testing/selftests/arm64/abi/hwcap.c
> index 35f521e5f41c..a539eeb0bfc0 100644
> --- a/tools/testing/selftests/arm64/abi/hwcap.c
> +++ b/tools/testing/selftests/arm64/abi/hwcap.c
> @@ -1098,6 +1098,12 @@ static const struct hwcap_data {
>  		.sigill_fn = hbc_sigill,
>  		.sigill_reliable = true,
>  	},
> +	{
> +		.name = "MTE_FAR",
> +		.at_hwcap = AT_HWCAP3,
> +		.hwcap_bit = HWCAP3_MTE_FAR,
> +		.cpuinfo = "mte_far",
> +	},
>  };

This is all good but I'd also like to see a test to check the FAR_EL1
bits are actually exposed to the signal handler when the hwcap is
present.

-- 
Catalin

Re: [PATCH v3 3/3] tools/kselftest: add MTE_FAR hwcap test

[Yeoreum Yun]

Hi Catalin,

> On Thu, Apr 10, 2025 at 08:47:21AM +0100, Yeoreum Yun wrote:
> > diff --git a/tools/testing/selftests/arm64/abi/hwcap.c b/tools/testing/selftests/arm64/abi/hwcap.c
> > index 35f521e5f41c..a539eeb0bfc0 100644
> > --- a/tools/testing/selftests/arm64/abi/hwcap.c
> > +++ b/tools/testing/selftests/arm64/abi/hwcap.c
> > @@ -1098,6 +1098,12 @@ static const struct hwcap_data {
> >  		.sigill_fn = hbc_sigill,
> >  		.sigill_reliable = true,
> >  	},
> > +	{
> > +		.name = "MTE_FAR",
> > +		.at_hwcap = AT_HWCAP3,
> > +		.hwcap_bit = HWCAP3_MTE_FAR,
> > +		.cpuinfo = "mte_far",
> > +	},
> >  };
>
> This is all good but I'd also like to see a test to check the FAR_EL1
> bits are actually exposed to the signal handler when the hwcap is
> present.
>

Okay. I'll integrate the address tag check test into check_mamp_option.

--
Sincerely,
Yeoreum Yun

Re: [PATCH v3 0/3] support FEAT_MTE_TAGGED_FAR feature

[Yeoreum Yun]

Gentle ping in case of forgotten

> The FEAT_MTE_TAGGED_FAR feature provides support for
> reporting all non-address bits during a synchronous MTE tag check fault.
>
> This patchset extends the reporting tag to include
> not only the memory tag (logical tag) but also the address tag via
> si_addr when FEAT_MTE_TAGGED_FAR feature is supported.
>
> Since v1:
>   - add hwcap test for MTE_FAR feature.
>   - add MTE_FAR doc into elf_hwcap.rst
>
> Since v2:
>   - Rebase to 6.15-rc1
>
> Yeoreum Yun (3):
>   arm64: add FEAT_MTE_TAGGED_FAR feature
>   arm64/mm/fault: use original FAR_EL1 value when ARM64_MTE_FAR is
>     supported
>   tools/kselftest: add MTE_FAR hwcap test
>
>  Documentation/arch/arm64/elf_hwcaps.rst      |  3 +++
>  Documentation/arch/arm64/tagged-pointers.rst | 11 ++++++-----
>  arch/arm64/include/asm/hwcap.h               |  1 +
>  arch/arm64/include/uapi/asm/hwcap.h          |  1 +
>  arch/arm64/kernel/cpufeature.c               |  9 +++++++++
>  arch/arm64/kernel/cpuinfo.c                  |  1 +
>  arch/arm64/mm/fault.c                        |  7 +++++--
>  arch/arm64/tools/cpucaps                     |  1 +
>  tools/testing/selftests/arm64/abi/hwcap.c    |  6 ++++++
>  9 files changed, 33 insertions(+), 7 deletions(-)
>
> --
> LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}
>

--
Sincerely,
Yeoreum Yun