From: Jim MacArthur <jim.macarthur@linaro.org>
To: qemu-devel@nongnu.org
Cc: richard.henderson@linaro.org
Subject: Re: [PATCH 2/3] target/arm/ptw.c: Add two new spaces to the granule protection case
Date: Fri, 17 Apr 2026 10:53:12 +0100 [thread overview]
Message-ID: <aeIDCF8FO8T9FEl1@linaro.org> (raw)
In-Reply-To: <5fb0432b-6c1c-40bc-b022-939d73f2115d@linaro.org>
On Fri, Apr 17, 2026 at 08:36:52AM +1000, Richard Henderson wrote:
> On 4/16/26 21:12, Jim MacArthur wrote:
> > This makes no functional difference, it just marks out two cases for
> > future use.
> >
> > Signed-off-by: Jim MacArthur <jim.macarthur@linaro.org>
> > ---
> > target/arm/ptw.c | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/target/arm/ptw.c b/target/arm/ptw.c
> > index 7b993bb5b3..d4b63a365a 100644
> > --- a/target/arm/ptw.c
> > +++ b/target/arm/ptw.c
> > @@ -510,6 +510,11 @@ bool arm_granule_protection_check(ARMGranuleProtectionConfig config,
> > break;
> > case 0b1111: /* all access */
> > return true;
> > + case 0b0100: /* system agent only */
> > + case 0b0101: /* non-secure protected */
> > + /* System Agent and Non-secure Protected are GDI extensions. */
> > + /* No processing element should have access to these. */
> > + goto fault_walk;
> > case 0b1000: /* secure */
> > if (!config.support_sel2) {
> > goto fault_walk;
> >
>
> There's no real point to this patch, since we get the same effect from the default case.
>
> It should be trivial to "properly" implement these two cases for the CPU, since
>
> R_QCLPTA: PE is not permitted to access memory within the NSP
> or the SA PA spaces, from any Security state.
>
> Access to these spaces is only allowed from external devices via the SMMU.
>
> The only effect on the PE is to check the various GPCCR fields (SA, NSP,
> NA6, NA7) to transform them from one type of fault to another: fault_walk ->
> fault_fail (i.e. break).
The thing that held me back here was the mapping from 'Reserved' in the table in D9.6.5 to fault_walk, which wasn't clear in the documentation, and hence leaving the behaviour unchanged. However, I would agree that we can map (GPCCR.SA=1, gpi=0x0x100) to fault_fail and so on and leave the (SA=0, 0b0100) case to what it would have been before (fault_walk).
Thanks for your feedback,
Jim
next prev parent reply other threads:[~2026-04-17 9:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-16 11:12 [PATCH 0/3] FEAT_RME_GDI initial work Jim MacArthur
2026-04-16 11:12 ` [PATCH 1/3] target/arm/cpu-features.c: Add RMEGDI to AA64MMFR4 Jim MacArthur
2026-04-16 22:13 ` Richard Henderson
2026-04-17 8:43 ` Peter Maydell
2026-04-16 11:12 ` [PATCH 2/3] target/arm/ptw.c: Add two new spaces to the granule protection case Jim MacArthur
2026-04-16 22:36 ` Richard Henderson
2026-04-17 9:53 ` Jim MacArthur [this message]
2026-04-16 11:12 ` [PATCH 3/3] tests/tcg/aarch64/system/rme_gdi.c: Very basic test of GDI Jim MacArthur
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=aeIDCF8FO8T9FEl1@linaro.org \
--to=jim.macarthur@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.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.