On Mon, 14 Sept 2026 at 19:12, Richard Henderson <[email protected]> wrote: > > On 9/14/26 07:51, Peter Maydell wrote: > > On Mon, 14 Sept 2026 at 18:21, Richard Henderson > > <[email protected]> wrote: > >> > >> On 9/13/26 23:16, Peter Maydell wrote: > >>> On Thu, 6 Aug 2026 at 18:32, Richard Henderson > >>> <[email protected]> wrote: > >>>> > >>>> It is IMPLEMENTATION DEFINED whether HCR_EL2.TID3 traps on registers > >>>> within the range which are not explicitly listed. Previously we chose > >>>> not to honor the TID3 bit. > >>>> > >>>> However, with FEAT_IDTE3 it becomes mandatory to honor SCR_EL3.TID3 > >>>> on these registers, so we might as well honor HCR_EL2.TID3 too. > >>> > >>> I thought we agreed not to change the behaviour here? Is this > >>> just a "forgot to update commit message" thing? > >> Oh, yes. Because I did update the code to test for v8 in translate.c. > > > > So what does this patch do? Is it just a no-behaviour-change > > refactor so we have a place to add the SCR_EL3.TID3 check > > in the following patch ? > It does what it says on the tin -- it honors HCR_EL2.TID3 for undefined > registers. We currently only do this via access_tid3 for defined registers.
But there aren't any genuinely UNDEFINED encodings in the TID3 space, are there? The ID register space has to RES0, not UNDEF, for reserved encodings, and so we have cpreg structs for all the reserved encodings in the ID space. We give the ones in the TID3 space either the access_tid3() accessfn (which honours HCR_TID3 only for v8) or access_v7a_tid3() (which always traps on HCR_TID3 and which we use for exactly the set of registers that were defined in v7A). -- PMM
