Re: [PATCH v7 17/20] target/arm: Rebuild hflags at MSR writes

[Peter Maydell]

On Fri, 18 Oct 2019 at 15:30, Richard Henderson
<address@hidden> wrote:
>
> On 10/18/19 5:32 AM, Peter Maydell wrote:
> > On Thu, 17 Oct 2019 at 19:51, Richard Henderson
> > <address@hidden> wrote:
> > Why only rebuild hflags if !ARM_CP_SUPPRESS_TB_END ?
> > For instance on the Xscale CPUs we set SUPPRESS_TB_END for the SCTLR,
> > but some of the SCTLR bits are cached in hflags, right? Do we somehow
> > arrange to rebuild the hflags when the TB does eventually end ?
>
> No, we don't.  I assumed that all registers which change TB flags would in 
> fact
> end the TB.
>
> Why did we suppress tb end for Xscale?

The comment in helper.c explains:
            /* Normally we would always end the TB on an SCTLR write, but Linux
             * arch/arm/mach-pxa/sleep.S expects two instructions following
             * an MMU enable to execute from cache.  Imitate this behaviour.
             */

This refers to an older version of the kernel code than the current one:
https://elixir.bootlin.com/linux/v2.6.11/source/arch/arm/mach-pxa/sleep.S#L166
which assumed that the two insns after the SCTLR write that enables
the MMU run from cache and so don't need to actually be accessible
via the addresses that the pre-MMU-enable code runs from.
This bit of kernel magic eventually went away with commit 4f5ad99bb5331c57
(kernel v2.6.39) which converted the PXA to use the generic suspend/resume
support, which presumably handles the enable-the-MMU transition in a more
sensible fashion where the address it's executing from is valid
both before and after the MMU is enabled.

thanks
-- PMM