tlbi va, vaa vs. val, vaal

[will.deacon@arm.com (Will Deacon)]

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