[PATCH v7 07/14] iommu/arm-smmu-v3: Thread SSID through the arm_smmu_attach_*() interface

[Nicolin Chen]

On Wed, May 08, 2024 at 03:57:15PM -0300, Jason Gunthorpe wrote:
> Allow creating and managing arm_smmu_mater_domain's with a non-zero SSID
> through the arm_smmu_attach_*() family of functions. This triggers ATC
> invalidation for the correct SSID in PASID cases and tracks the
> per-attachment SSID in the struct arm_smmu_master_domain.
> 
> Generalize arm_smmu_attach_remove() to be able to remove SSID's as well by
> ensuring the ATC for the PASID is flushed properly.
> 
> Tested-by: Nicolin Chen <nicolinc at nvidia.com>
> Tested-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
> Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>

Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>

> @@ -2689,11 +2692,14 @@ static void arm_smmu_attach_commit(struct arm_smmu_master *master,
>  		 * SMMU is translating for the new domain and both the old&new
>  		 * domain will issue invalidations.
>  		 */
> -		arm_smmu_atc_inv_master(master);
> +		if (state->want_ats)
> +			arm_smmu_atc_inv_master(master, state->ssid);

Just trying to confirm my understanding here:

In the arm_smmu_set_pasid pathway, ssid is a valid pasid. So,
here we invalidate both new and old master_domains using the
same ssid/pasid, if either of them occupies the same cd entry.

And...

> -	arm_smmu_remove_master_domain(master, state->old_domain);
> +	arm_smmu_remove_master_domain(master, state->old_domain, state->ssid);

then we remove the old one here.

Though the flow makes sense to me, yet I wonder if there can be
such a use case like this where an old master_domain is holding
the same cd entry as the one wanted by the new master_domain?

Thanks
Nicolin