qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Gustavo Romero <gustavo.romero@linaro.org>
To: Gabriel Brookman <brookmangabriel@gmail.com>, qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>, qemu-arm@nongnu.org
Subject: Re: [PATCH] target/arm: add support for FEAT_MTE_TAGGED_FAR
Date: Wed, 5 Nov 2025 18:49:10 +0100	[thread overview]
Message-ID: <9b196058-a0e3-422e-86a6-7c405681bf42@linaro.org> (raw)
In-Reply-To: <20251104-feat-mte-tagged-far-v1-1-cdfd7db40397@gmail.com>

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


  reply	other threads:[~2025-11-05 17:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-04 20:50 [PATCH] target/arm: add support for FEAT_MTE_TAGGED_FAR Gabriel Brookman
2025-11-05 17:49 ` Gustavo Romero [this message]
2025-11-06 10:31   ` Peter Maydell
2025-11-06 11:44     ` Gustavo Romero
2025-11-06 21:01       ` Gabriel Brookman

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=9b196058-a0e3-422e-86a6-7c405681bf42@linaro.org \
    --to=gustavo.romero@linaro.org \
    --cc=brookmangabriel@gmail.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).