qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v6 00/20] target/arm: Reduce overhead of cpu_get_tb_cpu_state


From: Peter Maydell
Subject: Re: [PATCH v6 00/20] target/arm: Reduce overhead of cpu_get_tb_cpu_state
Date: Thu, 17 Oct 2019 18:01:49 +0100

On Thu, 17 Oct 2019 at 17:25, Richard Henderson
<address@hidden> wrote:
>
> On 10/17/19 8:26 AM, Peter Maydell wrote:
> > Don't we also need to do something to rebuild the hflags
> > for M-profile writes to the memory mapped system registers?
> > For instance rebuild_hflags_m32() bakes in state which
> > cares about env->v7m.ccr, which is set via nvic_writel(),
> > but I don't see anything whereby the write to the NVIC
> > register triggers a rebuild of the hflags value. Maybe I
> > missed it?
>
> How do you end the TB after nvic_writel(), so that the new behaviour can be
> noticed right now?  We can call arm_rebuild_hflags() within nvic_writel(), but
> it still needs to be recognized somehow.  I would expect to place one rebuild
> in the place you end the TB...

To copy my reply from irc, just for the record:

we don't end the TB specifically after a write to the NVIC.
This is permitted by the architecture: rules R_BMLS and R_WQQB from
DDI05533B.h v8M Arm ARM:

# R_BMLS The side effects of any access to the SCS that performs
# a context-altering operation take effect when the access
# completes. A DSB instruction can be used to guarantee completion
# of a previous SCS access.
#
# R_WQQB A context synchronization event guarantees that the side
# effects of a previous SCS access are visible to all instructions
# in program order following the context synchronization event.

A context synchronization event is basically an ISB or an
exception entry/exit. Since we do end the TLB on an ISB
or exception entry/exit I think we're within the architectural
rules, but we do need to do a rebuild-hflags somewhere.
At the end of  nvic_sysreg_write() seems like the best place as
it means that QEMU is internally consistent and not likely to
trip over itself.

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]