On 8/30/25 1:40 PM, Richard Henderson wrote:
> We are required to skip DB update for AT instructions, and
> we are allowed to skip AF updates.  Choose to skip both.
> 
> Reviewed-by: Pierrick Bouvier <[email protected]>
> Signed-off-by: Richard Henderson <[email protected]>
> ---
>  target/arm/ptw.c | 15 ++++++++++++++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/target/arm/ptw.c b/target/arm/ptw.c
> index 8925c9a610..089eeff845 100644
> --- a/target/arm/ptw.c
> +++ b/target/arm/ptw.c
> @@ -58,6 +58,12 @@ typedef struct S1Translate {
>       * and will not change the state of the softmmu TLBs.
>       */
>      bool in_debug;
> +    /*
> +     * in_at: is this AccessType_AT?
> +     * This is also set for debug, because at heart that is also
> +     * an address translation, and simplifies a test.
> +     */
> +    bool in_at;
>      /*
>       * If this is stage 2 of a stage 1+2 page table walk, then this must
>       * be true if stage 1 is an EL0 access; otherwise this is ignored.
> @@ -1929,7 +1935,12 @@ static bool get_phys_addr_lpae(CPUARMState *env, 
> S1Translate *ptw,
>      descaddr &= ~(hwaddr)(page_size - 1);
>      descaddr |= (address & (page_size - 1));
>  
> -    if (likely(!ptw->in_debug)) {
> +    /*
> +     * For AccessType_AT, DB is not updated (AArch64.SetDirtyFlag),
> +     * and it is IMPLEMENTATION DEFINED whether AF is updated
> +     * (AArch64.SetAccessFlag; qemu chooses to not update).
> +     */
> +    if (likely(!ptw->in_at)) {
>          /*
>           * Access flag.
>           * If HA is enabled, prepare to update the descriptor below.

|           * Otherwise, pass the access fault on to software.
|           */
|          if (!(descriptor & (1 << 10))) {
|              if (param.ha) {
|                  new_descriptor |= 1 << 10; /* AF */
|              } else {
|                  fi->type = ARMFault_AccessFlag;
|                  goto do_fault;

This also skips the access flag fault which could be generated by an AT
instruction. Is this an expected change?

Thanks,
Zenghui

Reply via email to