From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58549) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WmkWe-0004kD-Uh for qemu-devel@nongnu.org; Tue, 20 May 2014 09:56:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WmkWV-0005MK-TP for qemu-devel@nongnu.org; Tue, 20 May 2014 09:56:16 -0400 Received: from mail-pa0-x22a.google.com ([2607:f8b0:400e:c03::22a]:52643) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WmkWV-0005MF-NG for qemu-devel@nongnu.org; Tue, 20 May 2014 09:56:07 -0400 Received: by mail-pa0-f42.google.com with SMTP id rd3so347513pab.29 for ; Tue, 20 May 2014 06:56:06 -0700 (PDT) Date: Tue, 20 May 2014 23:55:45 +1000 From: "Edgar E. Iglesias" Message-ID: <20140520135545.GK18802@zapo.iiNet> References: <1400491383-6725-1-git-send-email-edgar.iglesias@gmail.com> <1400491383-6725-23-git-send-email-edgar.iglesias@gmail.com> <20140520132846.GJ18802@zapo.iiNet> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [Qemu-devel] [PATCH v3 22/22] RFC: target-arm: Use a 1:1 mapping between EL and MMU index List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: "rob.herring@linaro.org" , "peter.crosthwaite@xilinx.com" , Aggeler Fabian , "qemu-devel@nongnu.org" , "agraf@suse.de" , "john.williams@xilinx.com" , "alex.bennee@linaro.org" , "christoffer.dall@linaro.org" , "rth@twiddle.net" On Tue, May 20, 2014 at 02:47:49PM +0100, Peter Maydell wrote: > On 20 May 2014 14:28, Edgar E. Iglesias 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