From mboxrd@z Thu Jan 1 00:00:00 1970 From: Will Deacon Subject: Re: tlbi va, vaa vs. val, vaal Date: Fri, 27 Feb 2015 10:33:47 +0000 Message-ID: <20150227103347.GE3628@arm.com> References: <54EFB670.2070501@samsung.com> <20150227102435.GC3628@arm.com> <54F046F2.7020705@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 4DE5046C50 for ; Fri, 27 Feb 2015 05:27:57 -0500 (EST) Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cr4PCy9yKtl for ; Fri, 27 Feb 2015 05:27:56 -0500 (EST) Received: from foss.arm.com (foss.arm.com [217.140.101.70]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 8CA4A46C4E for ; Fri, 27 Feb 2015 05:27:56 -0500 (EST) Content-Disposition: inline In-Reply-To: <54F046F2.7020705@arm.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu To: Marc Zyngier Cc: "kvmarm@lists.cs.columbia.edu" , "linux-arm-kernel@lists.infradead.org" List-Id: kvmarm@lists.cs.columbia.edu On Fri, Feb 27, 2015 at 10:29:06AM +0000, Marc Zyngier wrote: > On 27/02/15 10:24, Will Deacon wrote: > > On Fri, Feb 27, 2015 at 12:12:32AM +0000, Mario Smarduch wrote: > >> I noticed kernel tlbflush.h use tlbi va*, vaa* variants instead of > >> val, vaal ones. Reading the manual D.5.7.2 it appears that > >> va*, vaa* versions invalidate intermediate caching of > >> translation structures. > >> > >> With stage2 enabled that may result in 20+ memory lookups > >> for a 4 level page table walk. That's assuming that intermediate > >> caching structures cache mappings from stage1 table entry to > >> host page. > > > > Yeah, Catalin and I discussed improving the kernel support for this, > > but it requires some changes to the generic mmu_gather code so that we > > can distinguish the leaf cases. I'd also like to see that done in a way > > that takes into account different granule sizes (we currently iterate > > over huge pages in 4k chunks). Last time I touched that, I entered a > > world of pain and don't plan to return there immediately :) > > > > Catalin -- feeling brave? > > > > FWIW: the new IOMMU page-table stuff I just got merged *does* make use > > of leaf-invalidation for the SMMU. > > Now, talking about feeling brave: who will be silly enough to port KVM > to the IOMMU page table code? It should just work(tm), right? I suspect you'll need to do some surgery to the interfaces, which currently map directly onto the IOMMU API and therefore make nice assumptions about what we get asked to map/unmap. You also probably want a wider range of permissions than we use on the SMMU. Finally, the runtime nature of the code (we make no assumptions about address sizes, page sizes etc) probably incurs a performance hit that you may or may not care about. Will