Re: [PATCH rfcv1 7/8] iommu/arm-smmu-v3: Add arm_smmu_invs based arm_smmu_domain_inv_range()

On Mon, Sep 08, 2025 at 11:19:40AM -0700, Nicolin Chen wrote:

On Mon, Sep 08, 2025 at 12:39:11PM -0300, Jason Gunthorpe wrote:

quoted

On Sat, Sep 06, 2025 at 01:12:33AM -0700, Nicolin Chen wrote:

quoted

I know that performance-wise, this piece will be a quick respin,
as the attach side releases the lock very fast. It still looks
a bit complicated. And practically, it would respin even if the
attachment removes a non-PCI device, right?

If you are paying the cost of taking the lock then it should become
fully locked and consistent.

Well, the point is that the reader doesn't know if an ATS entry
is getting removed, and it can only speculate by looking at the
full list.

It doesn't care. It knows if it has to get a full lock or not, that's
it.

So, would it be better to just always take the read lock, while
applying the ATS condition to the writer side:

No, the whole optimization is to avoid read side locking on the fairly
common no-ATS case.

Always taking the lock destroys that.

Jsaon