Re: [PATCH v6 04/25] iommu/arm-smmu-v3: Move TLB range invalidation into common code

[Mostafa Saleh <smostafa@google.com>]

On Tue, May 05, 2026 at 01:17:09PM -0300, Jason Gunthorpe wrote:
> On Mon, May 04, 2026 at 12:15:17PM +0000, Mostafa Saleh wrote:
> 
> > I am not sure if it’s worth it, the hypervisor is much simpler, there
> > is a single page table, it’s locked (also identity mapped), it’s
> > updated on VM boot/teardown only, we don’t even use iotlb_gather at
> > the moment, although possible but I wanted to keep this series as
> > simple as I can then we can add more features later.
> > So this patch is the least intrusive change, as whatever the main SMMUv3
> > driver does, the range tlb invalidation logic is the same.
> > But I am happy to experiment with that when posted.
> 
> Okay, then maybe just always push a full invalidation?

Like full address space invalidation? that will not be optimal and will
affect every device on the system, why would we do that if we know the address?

> 
> I didn't like seeing the range invalidation lifted out, especially how
> ugly that will turn into after my next series. So, don't use range or
> use the proper full gather flow seem like the right two options.
> 
> I'm not so interested in minimal change, but maximum forward
> maintainability. It is much easier to manage if you double compile
> more of the driver exactly the same, and call functions in a fairly
> normal way vs make special cases and special functions..

Let me try with your series, but the core range invalidation shouldn’t
be changed often as it is tied to the hardware and wrapping it in a macro
is reasonable (just like the CPU tlb invalidation)
The last time this code was changed was in 2023.
I am happy to use higher level functions to improve the driver maintainability,
but I don’t see what is the problem at the moment.

Thanks,
Mostafa

> 
> Jason