On 21 April 2017 at 18:59, Richard Henderson <r...@twiddle.net> wrote:
> On 04/21/2017 10:23 AM, Peter Maydell wrote:
>> So, just how expensive is having an extra MMU mode which isn't
>> actually used? Is it bad enough to be worth the reduced
>> maintainability?
> Once you get above 7 indicies, we will start to reduce the size of the TLB
> for various hosts. See CPU_TLB_BITS in include/exec/cpu-defs.h.
That should be "above 8", right?
#define CPU_TLB_BITS \
MIN(8, \
TCG_TARGET_TLB_DISPLACEMENT_BITS - CPU_TLB_ENTRY_BITS - \
(NB_MMU_MODES <= 1 ? 0 : \
NB_MMU_MODES <= 2 ? 1 : \
NB_MMU_MODES <= 4 ? 2 : \
NB_MMU_MODES <= 8 ? 3 : 4))
Given that the worst case TCG_TARGET_TLB_DISPLACEMENT_BITS
is 16 (ARM, PPC, MIPS) and CPU_TLB_ENTRY_BITS 5, it's
only the NB_MMU_MODES 9 or more that reduces CPU_TLB_BITS
below 8.
So I have one more "free" mmu index for ARM, after which
it starts to cost us on ARM/PPC/MIPS hosts.
Unfortunately for v8M we're going to want "HFNMIENA, Secure"
as another index, which would be over 8. I'll have a play with
an approach where we have a wider set of index values within
target/arm code which we translate to/from MMU indexes when
we interact with the core TLB code.
thanks
-- PMM
