[Qemu-devel] How expensive is an extra QEMU TLB MMU index ?

[Qemu-devel] How expensive is an extra QEMU TLB MMU index ?

[Peter Maydell]

Hi; I have a feature for the ARM M profile emulation which I think
needs to be implemented by giving it a separate mmu index value.
[The HFNMIENA control bit allows "privileged and execution priority
is higher than 0" to run with the MPU effectively off even if normal
privileged execution has enabled the MPU.]

I could implement this by just bumping ARM's NB_MMU_MODES to 8
and using the extra value for this. On the other hand, several
of the current 7 index values are not needed for M profile CPUs,
so in theory I could reuse one of those (so it would have different
meanings if the CPU was M profile or not). But that feels like it would
be pretty accident-prone, since so much of the code is shared.

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?

thanks
-- PMM

Re: [Qemu-devel] How expensive is an extra QEMU TLB MMU index ?

[Richard Henderson]

On 04/21/2017 10:23 AM, Peter Maydell wrote:
> Hi; I have a feature for the ARM M profile emulation which I think
> needs to be implemented by giving it a separate mmu index value.
> [The HFNMIENA control bit allows "privileged and execution priority
> is higher than 0" to run with the MPU effectively off even if normal
> privileged execution has enabled the MPU.]
>
> I could implement this by just bumping ARM's NB_MMU_MODES to 8
> and using the extra value for this. On the other hand, several
> of the current 7 index values are not needed for M profile CPUs,
> so in theory I could reuse one of those (so it would have different
> meanings if the CPU was M profile or not). But that feels like it would
> be pretty accident-prone, since so much of the code is shared.
>
> 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 said, the size reduction doesn't happen for x86_64 host, and ought not 
actively fail for any host, so maybe you don't care.


r~

Re: [Qemu-devel] How expensive is an extra QEMU TLB MMU index ?

[Peter Maydell]

On 21 April 2017 at 18:59, Richard Henderson <rth@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