On Tue, May 20, 2014 at 02:47:49PM +0100, Peter Maydell wrote: > On 20 May 2014 14:28, Edgar E. Iglesias <edgar.igles...@gmail.com> 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
