Re: [PATCH 1/6] target/arm: Add FGWTE3_EL3

On Fri, 31 Jul 2026 at 20:15, Richard Henderson
<[email protected]> wrote:
>
> On 7/31/26 09:30, Peter Maydell wrote:
> >> @@ -553,7 +553,7 @@ typedef struct CPUArchState {
> >>            * FEAT_FGT2 will add more elements to these arrays.
> >>            */
> >>           uint64_t fgt_read[2]; /* HFGRTR, HDFGRTR */
> >> -        uint64_t fgt_write[2]; /* HFGWTR, HDFGWTR */
> >> +        uint64_t fgt_write[3]; /* HFGWTR, HDFGWTR, FGWTE3 */
> >>           uint64_t fgt_exec[1]; /* HFGITR */
> >
> > GICv5 also has some new fgt registers, incidentally; implementation
> > of them in my w-i-p gicv5 branch:
> > https://gitlab.com/pm215/qemu/-/commit/31900667e440a136c60b984c9e7c9e9a95d708df
> >
> > I don't think there's any particular clash here, though. The
> > one thing I do wonder about is that FGWTE3 has only a
> > write trap version, whereas the gicv5 regs have both read
> > and write trap versions. We rely on being able to use the same
> > index for fgt_read[] and fgt_write[].
>
> We do?  Where?
>
> E.g. HFGRTR and HFGWTR have separate names, and could therefore can have separate indexes
> in cpregs.h.

For registers that can be FGT-trapped independently for both read and
write, we put only a single index and bitpos into ri->fgt, and then
access_check_cp_reg will look the index up in either fgt_read[] or
fgt_write[] depending on whether the access is a read or not.
Essentially we rely on the read-trap config registers and the
write-trap config registers being in pairs with identical layout
so we don't have to separately store an (index,bitpos) for R and W.

(fgt_exec[] has an independent order because "this is a sysreg
we check for an exec-trap" overrides looking at whether it's
a read or a write.)

thanks
-- PMM