qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3 22/22] RFC: target-arm: Use a 1:1 mapping bet


From: Edgar E. Iglesias
Subject: Re: [Qemu-devel] [PATCH v3 22/22] RFC: target-arm: Use a 1:1 mapping between EL and MMU index
Date: Tue, 20 May 2014 23:55:45 +1000
User-agent: Mutt/1.5.21+155 (d3096e8796e7) (2012-12-30)

On Tue, May 20, 2014 at 02:47:49PM +0100, Peter Maydell wrote:
> On 20 May 2014 14:28, Edgar E. Iglesias <address@hidden> wrote:
> > On Tue, May 20, 2014 at 09:47:47AM +0000, Aggeler  Fabian wrote:
> >> I guess this makes sense. Shouldn’t we implement two more MMUs to separate 
> >> S-EL0/EL0 and S-EL1/EL1
> >> at least for ARMv8 with EL3 running in Aarch64 state?
> >
> > Maybe with future patches. My understanding is that on aarch64 the world
> > switch between S/NS requires EL3 firmware to reprogram the TTBR regs.
> > Currently in QEMU, the re-programming of TTBR will flush the TLBs. We would
> > need to do something about that before adding MMU tables for aarch64 Secure
> > EL0/1 does any good. I think it's better to keep it simple for now and leave
> > this as a possible future optimization.
> >
> > Another possible future optimization is to add some kind of dynamic 
> > allocation
> > of a limited set of MMU tables for different ASIDs and VMIDs. For emulated
> > virtualization, it might help quite a bit.
> 
> I think the right way to do that is to have QEMU's TLB
> structure include some sort of general equivalent to the
> ASID/VMID mechanism (presumably other target CPUs have some
> equivalent). Then we can honour 'flush by ASID' as well.
> (We make a forlorn gesture in this direction with the
> completely ignored 'flush_global' parameter to tlb_flush().)

Makes sense.

Cheers,
Edgar

> 
> This is all definitely 'maybe future' stuff though.)
> 
> thanks
> -- PMM



reply via email to

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