qemu-arm
[Top][All Lists]
Advanced

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

Re: [PATCH 2/2] target/arm: Bail out early on 0-length tlb range invalid


From: Richard Henderson
Subject: Re: [PATCH 2/2] target/arm: Bail out early on 0-length tlb range invalidate
Date: Wed, 26 Jan 2022 10:34:20 +1100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0

On 1/26/22 9:06 AM, Peter Maydell wrote:
On Tue, 25 Jan 2022 at 22:05, Richard Henderson
<richard.henderson@linaro.org> wrote:

On 1/11/22 3:47 AM, Idan Horowitz wrote:
If the given range specifies no addresses to be flushed there's no reason
to schedule a function on all CPUs that does nothing.

Signed-off-by: Idan Horowitz <idan.horowitz@gmail.com>
---
   target/arm/helper.c | 4 ++++
   1 file changed, 4 insertions(+)

diff --git a/target/arm/helper.c b/target/arm/helper.c
index cfca0f5ba6..1e819835c2 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -4564,6 +4564,10 @@ static void do_rvae_write(CPUARMState *env, uint64_t 
value,
       length = tlbi_aa64_range_get_length(env, value);
       bits = tlbbits_for_regime(env, one_idx, baseaddr);

+    if (length == 0) {
+        return;
+    }
+
       if (synced) {
           tlb_flush_range_by_mmuidx_all_cpus_synced(env_cpu(env),
                                                     baseaddr,


Looks good.  I guess we could sort the extractions above so that we do

      length = ...;
      if (length == 0) {
          return;
      }

      addr = ...
      bits = ...

Either way,
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

Should we handle this in the tlb_flush_* functions themselves,
or is it just Arm that has to fix up a special case of "actually
the length is zero" ?

Hmm.  Probably should handle this in tlb_*, yes.
So far, Arm is the only user regardless.

r~





reply via email to

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