On Wed, 27 Dec 2023 at 22:50, Richard Henderson
<richard.hender...@linaro.org> wrote:
>
> 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?
Doesn't really seem worthwhile to me -- we only know this
for a couple of subcases of AT instructions, which aren't
all that common in guest execution, and the cost of
is_a64() is going to be completely swamped by the cost
of actually doing the address translation...
thanks
-- PMM
