On 12/18/23 22:32, Peter Maydell wrote:
Currently the code in target/arm/helper.c mostly checks the PAN bits in env->pstate or env->uncached_cpsr directly when it wants to know if PAN is enabled, because in most callsites we know whether we are in AArch64 or AArch32. We do have an arm_pan_enabled() function, but we only use it in a few places where the code might run in either an AArch32 or AArch64 context.For FEAT_NV, when HCR_EL2.{NV,NV1} is {1,1} PAN is always disabled even when the PSTATE.PAN bit is set, the "is PAN enabled" test becomes more complicated. Make all places that check for PAN use arm_pan_enabled(), so we have a place to put the FEAT_NV test. Signed-off-by: Peter Maydell <peter.mayd...@linaro.org> --- target/arm/helper.c | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/target/arm/helper.c b/target/arm/helper.c index 3270fb11049..4b0e46cfaae 100644 --- a/target/arm/helper.c +++ b/target/arm/helper.c @@ -263,6 +263,15 @@ void init_cpreg_list(ARMCPU *cpu) g_list_free(keys); }+static bool arm_pan_enabled(CPUARMState *env)+{ + if (is_a64(env)) { + return env->pstate & PSTATE_PAN; + } else { + return env->uncached_cpsr & CPSR_PAN; + } +}
Worth splitting out helpers aa{32,64}_pan_enabled to avoid the is_a64 check when context dictates?
Either way, Reviewed-by: Richard Henderson <richard.hender...@linaro.org> r~
