qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v7 05/32] target-arm: make arm_current_el() retu


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v7 05/32] target-arm: make arm_current_el() return EL3
Date: Mon, 19 Jan 2015 19:00:23 +0000

On 19 January 2015 at 17:44, Richard Henderson <address@hidden> wrote:
> On 01/19/2015 05:22 AM, Peter Maydell wrote:
>> Richard: do you have a feel for how expensive it is to
>> have lots and lots of mmu modes? I might be able to
>> merge "S EL1" with "NS EL1 stage 1+2" and ditto "S EL0"
>> with "NS EL0 stage1 + 2" but we'd need to do more TLB
>> flushing and it's not clear to me currently exactly
>> where the extra flushes would have to go...
>
> It's 10k per mmu mode, more or less.  That's what you've
> got to memset (to -1) whenever a flush occurs.

Hmm. If the tlb flush memset is the main perf issue, we
could let the target tell the generic code how many MMU
modes it was using at runtime. We might need 7 modes in
the general case, but we could avoid burdening "no TZ"
or "no virtualization" CPUs with the overhead of clearing
TLB entries that we never actually use.

Alternatively (better!), for a lot of the tlb_flush()es triggered
by target-arm code we could be more precise about the affected
mmu_idx values, since the common case is going to be
"NS EL1 did something that needs a TLB flush", and by definition
that can't affect TLB entries for EL2, EL3 or S-EL1/EL0.

So I think my preference would be to use 7 mmu indexes,
and add a tlb_flush_mmuidx() function. (Assuming I'm
not missing anything that makes that not workable...)

-- PMM



reply via email to

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