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.
The comment from v1 was about changing the behaviour of Armv7, which is
addressed in v2 by testing for Armv8:
+ /*
+ * With v8, we have the possibility of FEAT_FGT which requires
+ * trapping with HCR/HCR_EL2.TID3. Without FEAT_FGT, it is
+ * IMPLEMENTATION DEFINED whether TID3 affects IDs in the range
+ * that weren't explcitly listed. We choose to trap.
+ *
+ * With v7, there is vague language about "not required" to trap:
+ * see access_v7a_tid3. We choose to not trap.
+ */
+ if (arm_dc_feature(s, ARM_FEATURE_V8)
etc.
r~
