qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v1 05/22] target-arm: Add arm_el_to_mmu_idx()


From: Edgar E. Iglesias
Subject: Re: [Qemu-devel] [PATCH v1 05/22] target-arm: Add arm_el_to_mmu_idx()
Date: Sat, 17 May 2014 11:41:59 +1000
User-agent: Mutt/1.5.21+155 (d3096e8796e7) (2012-12-30)

On Sat, May 17, 2014 at 12:13:06AM +0200, Alexander Graf wrote:
> 
> On 17.05.14 00:10, Edgar E. Iglesias wrote:
> >On Fri, May 16, 2014 at 03:24:42PM +0100, Peter Maydell wrote:
> >>On 6 May 2014 07:08, Edgar E. Iglesias <address@hidden> wrote:
> >>>From: "Edgar E. Iglesias" <address@hidden>
> >>>
> >>>Maps a given EL to the corresponding MMU index.
> >>>
> >>>Signed-off-by: Edgar E. Iglesias <address@hidden>
> >>>---
> >>>  target-arm/cpu.h           | 21 ++++++++++++++++++++-
> >>>  target-arm/translate-a64.c |  8 ++------
> >>>  2 files changed, 22 insertions(+), 7 deletions(-)
> >>>
> >>>diff --git a/target-arm/cpu.h b/target-arm/cpu.h
> >>>index ff86250..938f389 100644
> >>>--- a/target-arm/cpu.h
> >>>+++ b/target-arm/cpu.h
> >>>@@ -1086,9 +1086,28 @@ static inline CPUARMState *cpu_init(const char 
> >>>*cpu_model)
> >>>  #define MMU_MODE0_SUFFIX _kernel
> >>>  #define MMU_MODE1_SUFFIX _user
> >>>  #define MMU_USER_IDX 1
> >>>+static inline int arm_el_to_mmu_idx(int current_el)
> >>>+{
> >>>+#ifdef CONFIG_USER_ONLY
> >>>+    return MMU_USER_IDX;
> >>>+#else
> >>>+    switch (current_el) {
> >>>+    case 0:
> >>>+        return MMU_USER_IDX;
> >>>+    case 1:
> >>>+        return 0;
> >>>+    default:
> >>>+        /* Unsupported EL.  */
> >>>+        assert(0);
> >>>+        return 0;
> >>>+    }
> >>>+#endif
> >>Can we just make the EL and the MMU index the same thing,
> >>or is secure-vs-nonsecure going to need its own MMU
> >>indexes anyway?
> >Right, I did the conversion to 1:1 mapping at an early stage
> >but avoided it as we will need an indirect mapping for
> >Secure EL0/1 anyway.
> 
> How often do we switch between secure and non-secure? If it doesn't happen
> all that often, we could just flush the TLB on every transition.

That's an option. I think this mostly affects aarch32 as that is where the
TTBR regs are banked. For aarch64 I think the world switching FW has
to rewrite the TTBR regs leading to TLB flushes anyway with current code.
IIUC..

I can include a switch over to 1:1 mapping between EL and MMU-idx if
preferd. I already have the patches but they will make this series
conflict alot more with the TZ patches on list.

Thanks,
Edgar



reply via email to

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