1. Patchew
  2. QEMU
  3. View series

[PATCH] target/arm: add support for FEAT_MTE_TAGGED_FAR

Gabriel Brookman posted 1 patch 1 week, 2 days ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20251104-feat-mte-tagged-far-v1-1-cdfd7db40397@gmail.com
Maintainers: Peter Maydell <peter.maydell@linaro.org>
target/arm/cpu.c       | 4 +++-
target/arm/tcg/cpu64.c | 4 ++++
2 files changed, 7 insertions(+), 1 deletion(-)
[PATCH] target/arm: add support for FEAT_MTE_TAGGED_FAR
Posted by Gabriel Brookman 1 week, 2 days ago 
FEAT_MTE_TAGGED_FAR is a feature required for MTE4. The feature
guarantees that the full address (including tag bits) is reported after
a SEGV_MTESERR, and advertises itself in the ID_AA64PFR2_EL1 system
register. QEMU was already reporting the full address, so this commit
simply advertises the feature by setting that register, and unsets the
register if MTE is disabled.

Signed-off-by: Gabriel Brookman <brookmangabriel@gmail.com>
---
This patch is the first step toward implementing ARM's Enhanced Memory
Tagging Extension (MTE4). MTE4 guarantees the presence of several
subfeatures: FEAT_MTE_CANONICAL_TAGS, FEAT_MTE_TAGGED_FAR,
FEAT_MTE_STORE_ONLY, FEAT_MTE_NO_ADDRESS_TAGS, and FEAT_MTE_PERM,
none of which are currently implemented in QEMU.

According to the ARM ARM, the presence of any of these features (except
FEAT_MTE_PERM) implies the presence of all the others. For simplicity
and ease of review, I plan to introduce them one at a time. This first
patch focuses on FEAT_MTE_TAGGED_FAR.

FEAT_MTE_TAGGED_FAR guarantees that the full fault address (including
tag bits) is reported after a SEGV_MTESERR, and exposes itself in the
ID_AA64PFR2_EL1 register. QEMU already reports the full address in this
case, so this change only advertises the feature by setting the
appropriate field in ID_AA64PFR2_EL1. The field is cleared when MTE
support is disabled or rolled back to instruction-only.

Testing:
- Verified in system mode that the MTEFAR field in ID_AA64PFR2_EL1
is set to 1 when running with mte=on and cleared with mte=off.
- Verified in user mode test that SEGV_MTESERR faults report the full
tagged address as expected.

I didn’t include these checks as formal tests since the functionality is
simple, but I can add them in follow-up versions if reviewers prefer.

Follow-up patches will implement the remaining MTE4 subfeatures listed
above.

Thanks,
Gabriel Brookman
---
 target/arm/cpu.c       | 4 +++-
 target/arm/tcg/cpu64.c | 4 ++++
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 39292fb9bc..804e70b235 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -2020,6 +2020,7 @@ static void arm_cpu_realizefn(DeviceState *dev, Error **errp)
          */
         if (tcg_enabled() && cpu->tag_memory == NULL) {
             FIELD_DP64_IDREG(isar, ID_AA64PFR1, MTE, 1);
+            FIELD_DP64_IDREG(isar, ID_AA64PFR2, MTEFAR, 0);
         }
 
         /*
@@ -2027,7 +2028,8 @@ static void arm_cpu_realizefn(DeviceState *dev, Error **errp)
          * enabled on the guest (i.e mte=off), clear guest's MTE bits."
          */
         if (kvm_enabled() && !cpu->kvm_mte) {
-                FIELD_DP64_IDREG(isar, ID_AA64PFR1, MTE, 0);
+            FIELD_DP64_IDREG(isar, ID_AA64PFR1, MTE, 0);
+            FIELD_DP64_IDREG(isar, ID_AA64PFR2, MTEFAR, 0);
         }
 #endif
     }
diff --git a/target/arm/tcg/cpu64.c b/target/arm/tcg/cpu64.c
index 6871956382..27f0b43256 100644
--- a/target/arm/tcg/cpu64.c
+++ b/target/arm/tcg/cpu64.c
@@ -1283,6 +1283,10 @@ void aarch64_max_tcg_initfn(Object *obj)
     t = FIELD_DP64(t, ID_AA64PFR1, GCS, 1);       /* FEAT_GCS */
     SET_IDREG(isar, ID_AA64PFR1, t);
 
+    t = GET_IDREG(isar, ID_AA64PFR2);
+    t = FIELD_DP64(t, ID_AA64PFR2, MTEFAR, 1);    /* FEAT_MTE_TAGGED_FAR */
+    SET_IDREG(isar, ID_AA64PFR2, t);
+
     t = GET_IDREG(isar, ID_AA64MMFR0);
     t = FIELD_DP64(t, ID_AA64MMFR0, PARANGE, 6); /* FEAT_LPA: 52 bits */
     t = FIELD_DP64(t, ID_AA64MMFR0, TGRAN16, 1);   /* 16k pages supported */

---
base-commit: e9c692eabbbb7f395347605a6ef33a32d398ea25
change-id: 20251104-feat-mte-tagged-far-c8d302a888ad

Best regards,
-- 
Gabriel Brookman <brookmangabriel@gmail.com>
Re: [PATCH] target/arm: add support for FEAT_MTE_TAGGED_FAR
Posted by Gustavo Romero 1 week, 1 day ago 
Hi Gabriel,

Thanks for your contribution.

On 11/4/25 21:50, Gabriel Brookman wrote:
> FEAT_MTE_TAGGED_FAR is a feature required for MTE4. The feature
> guarantees that the full address (including tag bits) is reported after
> a SEGV_MTESERR, and advertises itself in the ID_AA64PFR2_EL1 system
> register. QEMU was already reporting the full address, so this commit
> simply advertises the feature by setting that register, and unsets the
> register if MTE is disabled.
> 
> Signed-off-by: Gabriel Brookman <brookmangabriel@gmail.com>
> ---
> This patch is the first step toward implementing ARM's Enhanced Memory
> Tagging Extension (MTE4). MTE4 guarantees the presence of several
> subfeatures: FEAT_MTE_CANONICAL_TAGS, FEAT_MTE_TAGGED_FAR,
> FEAT_MTE_STORE_ONLY, FEAT_MTE_NO_ADDRESS_TAGS, and FEAT_MTE_PERM,
> none of which are currently implemented in QEMU.
> 
> According to the ARM ARM, the presence of any of these features (except
> FEAT_MTE_PERM) implies the presence of all the others. For simplicity
> and ease of review, I plan to introduce them one at a time. This first
> patch focuses on FEAT_MTE_TAGGED_FAR.

I think it's ok to add these "subfeatures" separately.

You need another patch to add FEAT_MTE_TAGGED_FAR to:

docs/system/arm/emulation.rst

Also, please adjust the title to something:

target/arm: Advertise FEAT_MTE_TAGGED_FAR for -cpu max

instead of "add support...", I think it's a better description for
the changes done here.


> FEAT_MTE_TAGGED_FAR guarantees that the full fault address (including
> tag bits) is reported after a SEGV_MTESERR, and exposes itself in the
> ID_AA64PFR2_EL1 register. QEMU already reports the full address in this
> case, so this change only advertises the feature by setting the
> appropriate field in ID_AA64PFR2_EL1. The field is cleared when MTE
> support is disabled or rolled back to instruction-only.
> 
> Testing:
> - Verified in system mode that the MTEFAR field in ID_AA64PFR2_EL1
> is set to 1 when running with mte=on and cleared with mte=off.

If you want to add a test like that it's good, yeah, but we don't usually
test the features this way.


> - Verified in user mode test that SEGV_MTESERR faults report the full
> tagged address as expected.

Yeah, that would be good if you can add a test like that. Maybe use
as a starting point some test in the mte-[1-8].c tests.

  > I didn’t include these checks as formal tests since the functionality is
> simple, but I can add them in follow-up versions if reviewers prefer.
> 
> Follow-up patches will implement the remaining MTE4 subfeatures listed
> above.
> 
> Thanks,
> Gabriel Brookman
> ---
>   target/arm/cpu.c       | 4 +++-
>   target/arm/tcg/cpu64.c | 4 ++++
>   2 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/target/arm/cpu.c b/target/arm/cpu.c
> index 39292fb9bc..804e70b235 100644
> --- a/target/arm/cpu.c
> +++ b/target/arm/cpu.c
> @@ -2020,6 +2020,7 @@ static void arm_cpu_realizefn(DeviceState *dev, Error **errp)
>            */
>           if (tcg_enabled() && cpu->tag_memory == NULL) {
>               FIELD_DP64_IDREG(isar, ID_AA64PFR1, MTE, 1);
> +            FIELD_DP64_IDREG(isar, ID_AA64PFR2, MTEFAR, 0);
>           }
>   
>           /*
> @@ -2027,7 +2028,8 @@ static void arm_cpu_realizefn(DeviceState *dev, Error **errp)
>            * enabled on the guest (i.e mte=off), clear guest's MTE bits."
>            */
>           if (kvm_enabled() && !cpu->kvm_mte) {
> -                FIELD_DP64_IDREG(isar, ID_AA64PFR1, MTE, 0);
> +            FIELD_DP64_IDREG(isar, ID_AA64PFR1, MTE, 0);
> +            FIELD_DP64_IDREG(isar, ID_AA64PFR2, MTEFAR, 0);
>           }
>   #endif
>       }
> diff --git a/target/arm/tcg/cpu64.c b/target/arm/tcg/cpu64.c
> index 6871956382..27f0b43256 100644
> --- a/target/arm/tcg/cpu64.c
> +++ b/target/arm/tcg/cpu64.c
> @@ -1283,6 +1283,10 @@ void aarch64_max_tcg_initfn(Object *obj)
>       t = FIELD_DP64(t, ID_AA64PFR1, GCS, 1);       /* FEAT_GCS */
>       SET_IDREG(isar, ID_AA64PFR1, t);
>   
> +    t = GET_IDREG(isar, ID_AA64PFR2);
> +    t = FIELD_DP64(t, ID_AA64PFR2, MTEFAR, 1);    /* FEAT_MTE_TAGGED_FAR */
> +    SET_IDREG(isar, ID_AA64PFR2, t);
> +
>       t = GET_IDREG(isar, ID_AA64MMFR0);
>       t = FIELD_DP64(t, ID_AA64MMFR0, PARANGE, 6); /* FEAT_LPA: 52 bits */
>       t = FIELD_DP64(t, ID_AA64MMFR0, TGRAN16, 1);   /* 16k pages supported */

The changes in code above look good to me.


Cheers,
Gustavo
Re: [PATCH] target/arm: add support for FEAT_MTE_TAGGED_FAR
Posted by Peter Maydell 1 week, 1 day ago 
On Wed, 5 Nov 2025 at 17:49, Gustavo Romero <gustavo.romero@linaro.org> wrote:
>
> Hi Gabriel,
>
> Thanks for your contribution.
>
> On 11/4/25 21:50, Gabriel Brookman wrote:
> > FEAT_MTE_TAGGED_FAR is a feature required for MTE4. The feature
> > guarantees that the full address (including tag bits) is reported after
> > a SEGV_MTESERR, and advertises itself in the ID_AA64PFR2_EL1 system
> > register. QEMU was already reporting the full address, so this commit
> > simply advertises the feature by setting that register, and unsets the
> > register if MTE is disabled.
> >
> > Signed-off-by: Gabriel Brookman <brookmangabriel@gmail.com>
> > ---
> > This patch is the first step toward implementing ARM's Enhanced Memory
> > Tagging Extension (MTE4). MTE4 guarantees the presence of several
> > subfeatures: FEAT_MTE_CANONICAL_TAGS, FEAT_MTE_TAGGED_FAR,
> > FEAT_MTE_STORE_ONLY, FEAT_MTE_NO_ADDRESS_TAGS, and FEAT_MTE_PERM,
> > none of which are currently implemented in QEMU.
> >
> > According to the ARM ARM, the presence of any of these features (except
> > FEAT_MTE_PERM) implies the presence of all the others. For simplicity
> > and ease of review, I plan to introduce them one at a time. This first
> > patch focuses on FEAT_MTE_TAGGED_FAR.
>
> I think it's ok to add these "subfeatures" separately.

We can add the implementation of the subfeatures separately,
but we should not enable them in 'max' until they're all
present. (We don't always adhere strictly to the architecture's
"feature X implies Y exists" rules, but in this case
because they're really a tightly linked bundle that add
up to "MTE4" I think that presnting only a subset to guests
is likely to result in them not behaving correctly.)

thanks
-- PMM
Re: [PATCH] target/arm: add support for FEAT_MTE_TAGGED_FAR
Posted by Gustavo Romero 1 week, 1 day ago 
Hi Peter,

On 11/6/25 11:31, Peter Maydell wrote:
> On Wed, 5 Nov 2025 at 17:49, Gustavo Romero <gustavo.romero@linaro.org> wrote:
>>
>> Hi Gabriel,
>>
>> Thanks for your contribution.
>>
>> On 11/4/25 21:50, Gabriel Brookman wrote:
>>> FEAT_MTE_TAGGED_FAR is a feature required for MTE4. The feature
>>> guarantees that the full address (including tag bits) is reported after
>>> a SEGV_MTESERR, and advertises itself in the ID_AA64PFR2_EL1 system
>>> register. QEMU was already reporting the full address, so this commit
>>> simply advertises the feature by setting that register, and unsets the
>>> register if MTE is disabled.
>>>
>>> Signed-off-by: Gabriel Brookman <brookmangabriel@gmail.com>
>>> ---
>>> This patch is the first step toward implementing ARM's Enhanced Memory
>>> Tagging Extension (MTE4). MTE4 guarantees the presence of several
>>> subfeatures: FEAT_MTE_CANONICAL_TAGS, FEAT_MTE_TAGGED_FAR,
>>> FEAT_MTE_STORE_ONLY, FEAT_MTE_NO_ADDRESS_TAGS, and FEAT_MTE_PERM,
>>> none of which are currently implemented in QEMU.
>>>
>>> According to the ARM ARM, the presence of any of these features (except
>>> FEAT_MTE_PERM) implies the presence of all the others. For simplicity
>>> and ease of review, I plan to introduce them one at a time. This first
>>> patch focuses on FEAT_MTE_TAGGED_FAR.
>>
>> I think it's ok to add these "subfeatures" separately.
> 
> We can add the implementation of the subfeatures separately,
> but we should not enable them in 'max' until they're all
> present.

ah, true. I forget that when we do that we enable them in 'max'
as a last step.


> (We don't always adhere strictly to the architecture's
> "feature X implies Y exists" rules,

Thanks for confirming it ;)


> but in this case
> because they're really a tightly linked bundle that add
> up to "MTE4" I think that presnting only a subset to guests
> is likely to result in them not behaving correctly.)

Gabriel, given what Peter explained above, although the patch
is correct, the best to move forward here is to embedded this
patch into the additional series that implements the others
"subfeatures" and, as a last step, after the patches that
implement the features, you enable all the features in 'max'.


Cheers,
Gustavo
Re: [PATCH] target/arm: add support for FEAT_MTE_TAGGED_FAR
Posted by Gabriel Brookman 1 week ago 
Gustavo,

Thanks for the review! It makes sense.

On Thu, Nov 06, 2025 at 12:44:23PM +0100, Gustavo Romero wrote:
> Gabriel, given what Peter explained above, although the patch
> is correct, the best to move forward here is to embedded this
> patch into the additional series that implements the others
> "subfeatures" and, as a last step, after the patches that
> implement the features, you enable all the features in 'max'.

Once I finish FEAT_MTE_STORE_ONLY I'll send a new series, which will
include the changes from this series, the STORE_ONLY implementation,
and also include patches for the updated documentation and tests for
FEAT_MTE_TAGGED_FAR as you requested. As I continue to write patches
for MTE4 features, I'll add them to that patchset and we can merge it
all at once.

Thanks,
Gabriel

On Thu, Nov 6, 2025 at 6:44 AM Gustavo Romero <gustavo.romero@linaro.org> wrote:
>
> Hi Peter,
>
> On 11/6/25 11:31, Peter Maydell wrote:
> > On Wed, 5 Nov 2025 at 17:49, Gustavo Romero <gustavo.romero@linaro.org> wrote:
> >>
> >> Hi Gabriel,
> >>
> >> Thanks for your contribution.
> >>
> >> On 11/4/25 21:50, Gabriel Brookman wrote:
> >>> FEAT_MTE_TAGGED_FAR is a feature required for MTE4. The feature
> >>> guarantees that the full address (including tag bits) is reported after
> >>> a SEGV_MTESERR, and advertises itself in the ID_AA64PFR2_EL1 system
> >>> register. QEMU was already reporting the full address, so this commit
> >>> simply advertises the feature by setting that register, and unsets the
> >>> register if MTE is disabled.
> >>>
> >>> Signed-off-by: Gabriel Brookman <brookmangabriel@gmail.com>
> >>> ---
> >>> This patch is the first step toward implementing ARM's Enhanced Memory
> >>> Tagging Extension (MTE4). MTE4 guarantees the presence of several
> >>> subfeatures: FEAT_MTE_CANONICAL_TAGS, FEAT_MTE_TAGGED_FAR,
> >>> FEAT_MTE_STORE_ONLY, FEAT_MTE_NO_ADDRESS_TAGS, and FEAT_MTE_PERM,
> >>> none of which are currently implemented in QEMU.
> >>>
> >>> According to the ARM ARM, the presence of any of these features (except
> >>> FEAT_MTE_PERM) implies the presence of all the others. For simplicity
> >>> and ease of review, I plan to introduce them one at a time. This first
> >>> patch focuses on FEAT_MTE_TAGGED_FAR.
> >>
> >> I think it's ok to add these "subfeatures" separately.
> >
> > We can add the implementation of the subfeatures separately,
> > but we should not enable them in 'max' until they're all
> > present.
>
> ah, true. I forget that when we do that we enable them in 'max'
> as a last step.
>
>
> > (We don't always adhere strictly to the architecture's
> > "feature X implies Y exists" rules,
>
> Thanks for confirming it ;)
>
>
> > but in this case
> > because they're really a tightly linked bundle that add
> > up to "MTE4" I think that presnting only a subset to guests
> > is likely to result in them not behaving correctly.)
>
> Gabriel, given what Peter explained above, although the patch
> is correct, the best to move forward here is to embedded this
> patch into the additional series that implements the others
> "subfeatures" and, as a last step, after the patches that
> implement the features, you enable all the features in 'max'.
>
>
> Cheers,
> Gustavo

Patchew 2.1-devel-b67e4c2

© 2016 - 2025 Red Hat, Inc.