tlbi va, vaa vs. val, vaal

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.

Quoted 9 lines · Mario Smarduch

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.

Quoted 18 lines · Will Deacon

Quoted 9 lines · Mario Smarduch

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 :)

Quoted 4 lines

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?

Quoted 19 lines · Marc Zyngier

Quoted 18 lines · Will Deacon

Quoted 9 lines · Mario Smarduch

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 :)

Quoted 7 lines

Quoted 4 lines

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.

Quoted 9 lines · Mario Smarduch

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.

Will

Quoted 20 lines · Will Deacon

Quoted 9 lines · Mario Smarduch

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?

Quoted 2 lines

FWIW: the new IOMMU page-table stuff I just got merged *does* make use of leaf-invalidation for the SMMU.

thanks for the background. I'm guessing how much of PTWalk
is cached is implementation dependent. One old paper quotes upto 40% improvement for some industry benchmarks that cache all stage1/2 PTWalk entries.

Quoted 24 lines · Mario Smarduch

Quoted 22 lines · Will Deacon

Quoted 9 lines · Mario Smarduch

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.

Quoted 4 lines

thanks for the background. I'm guessing how much of PTWalk
is cached is implementation dependent. One old paper quotes upto 40% improvement for some industry benchmarks that cache all stage1/2 PTWalk entries.

Is it caching in the TLB or in the level 1 CPU cache?

I would indeed expect some improvement without many drawbacks. The only thing we need in Linux is to distinguish between leaf TLBI and TLBI for page table tearing down. It's not complicated, it just needs some testing (strangely enough, I tried to replace all user TLBI with the L variants on a Juno board and no signs of any crashes).