qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 00/11] target-arm: handle mmu_idx/translation


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v2 00/11] target-arm: handle mmu_idx/translation regimes properly
Date: Fri, 30 Jan 2015 10:42:38 +0000

On 30 January 2015 at 01:36, Edgar E. Iglesias <address@hidden> wrote:
> IIRC, last time the dedicated S-EL0 and S-EL1 MMU idx came up the
> discussion went around flushing the qemu tlbs when switching between
> S/NS. Having the dedicated MMU-idx is faster but for Aarch64 I think
> we would need logic in at least the TTBRx access handlers to make use
> of the dedicated secure MMU idx as Aarch64 secure monitors need to
> reprogram the MMU when world switching.
>
> Another thing around the ARMMMUIdx_S2NS index.
> From what I've seen, what would really help is having a fast
> way to go from VM mode to non-vm mode. In particular for KVM.
> For example when a guest writes to a virtio console there is alot
> of ping-ponging between NS-S12(Guest) and NS-S1(Linux/KVM).
>
> Similary for XEN, it would really help to have that ASID/VMID indexed TLB I
> think you suggested at some point. In XEN's case the ping-ponging
> goes between two guests, domUs and dom0.

Yes, the lack of ASID/VMID restrictions on the TLB hurts us.
It's tricky to implement in s/w without it being slower than
what we have now, though.

> I'm not try to indicate that you should add any of that now,
> I'm just not sure sure it's worth adding the ARMMMUIdx_S2NS without
> trying if it will actually give any real life improvements in
> QEMU.

Mostly my aim here was to make sure we were actually treating
separately the various virt-to-phys mappings which the architecture
says are separate, so we don't have nasty "hit something stale
in the TLB" bugs to track down.

-- PMM



reply via email to

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