qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v6 30/41] target/arm: Flush tlb for ASID changes in EL2&0 tra


From: Peter Maydell
Subject: Re: [PATCH v6 30/41] target/arm: Flush tlb for ASID changes in EL2&0 translation regime
Date: Mon, 3 Feb 2020 11:36:08 +0000

On Sat, 1 Feb 2020 at 19:29, Richard Henderson
<address@hidden> wrote:
>
> Since we only support a single ASID, flush the tlb when it changes.
>
> Note that TCR_EL2, like TCR_EL1, has the A1 bit that chooses between
> the two TTBR* registers for the location of the ASID.
>
> Reviewed-by: Peter Maydell <address@hidden>
> Signed-off-by: Richard Henderson <address@hidden>
> ---
>  target/arm/helper.c | 22 +++++++++++++++-------
>  1 file changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/target/arm/helper.c b/target/arm/helper.c
> index cfa6ce59dc..f9be6b052f 100644
> --- a/target/arm/helper.c
> +++ b/target/arm/helper.c
> @@ -3763,7 +3763,7 @@ static void vmsa_ttbcr_reset(CPUARMState *env, const 
> ARMCPRegInfo *ri)
>      tcr->base_mask = 0xffffc000u;
>  }
>
> -static void vmsa_tcr_el1_write(CPUARMState *env, const ARMCPRegInfo *ri,
> +static void vmsa_tcr_el12_write(CPUARMState *env, const ARMCPRegInfo *ri,
>                                 uint64_t value)
>  {
>      ARMCPU *cpu = env_archcpu(env);
> @@ -3789,7 +3789,17 @@ static void vmsa_ttbr_write(CPUARMState *env, const 
> ARMCPRegInfo *ri,
>  static void vmsa_tcr_ttbr_el2_write(CPUARMState *env, const ARMCPRegInfo *ri,
>                                      uint64_t value)
>  {
> -    /* TODO: There are ASID fields in here with HCR_EL2.E2H */
> +    /*
> +     * If we are running with E2&0 regime, then an ASID is active.
> +     * Flush if that might be changing.  Note we're not checking
> +     * TCR_EL2.A1 to know if this is really the TTBRx_EL2 that
> +     * holds the active ASID, only checking the field that might.
> +     */
> +    if (extract64(raw_read(env, ri) ^ value, 48, 16) &&
> +        (arm_hcr_el2_eff(env) & HCR_E2H)) {
> +        tlb_flush_by_mmuidx(env_cpu(env),
> +                            ARMMMUIdxBit_E20_2 | ARMMMUIdxBit_E20_0);
> +    }
>      raw_write(env, ri, value);

Since we don't flush TLBs when HCR_EL2.E2H changes, I'm wondering
about this sequence:

 * initially HCR_EL2.E2H == 1 and the E2&0 TLBs are populated
 * HCR_EL2.E2H is set to 0
 * TTBR1_EL2 is written with a different ASID from step 1,
   but we don't flush the TLBs because HCR_EL2.E2H is 0
 * HCR_EL2.E2H is set to 1
 * guest will pick up wrong-ASID TLB entries from step 1

Does the architecture require that the guest did some TLB
maintenance ops somewhere along the line to avoid this?
I haven't tried to look for them, but given the different
ASIDs I'm not sure it does...

thanks
-- PMM



reply via email to

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