Re: [PATCH v4 06/17] iommu: Replace __iommu_group_dma_first_attach() with set_domain

[Jason Gunthorpe <jgg@nvidia.com>]

On Thu, Apr 20, 2023 at 07:25:59AM +0000, Tian, Kevin wrote:
> > From: Jason Gunthorpe <jgg@nvidia.com>
> > Sent: Wednesday, April 12, 2023 9:52 PM
> > 
> > @@ -2218,6 +2202,12 @@ static int __iommu_device_set_domain(struct
> > iommu_group *group,
> >  {
> >  	int ret;
> > 
> > +	if (dev->iommu->attach_deferred) {
> > +		if (new_domain == group->default_domain)
> > +			return 0;
> > +		dev->iommu->attach_deferred = 0;
> > +	}
> > +
> 
> This leads to a small semantics change, though I'm not sure whether it's
> important to sustain.
> 
> Before this patch the 1st attach is ignored. Deferred attach is conducted
> when the first DMA map request comes by calling iommu_deferred_attach().
> 
> But if the driver tries to do iommu_attach_group() or iommu_attach_device()
> in between it will succeed. No deferred_attach check in that path.
> 
> Now with this patch the behavior is changed. If the driver tries to attach the
> device to default domain in between it's ignored. Otherwise it will succeed.

Sort of..

If a driver is using the attach APIs then the first successfull attach
to a non-default domain will clear the flag, then any following attach
even back to the default domain will succeed.

The tiny difference is if a driver tries to attach to the already
attached domain the NOP now extends to keeping the defered attach too.

I don't think any drivers do something like this so it seems OK.

v3 didn't have this as the flag kept the different call paths
seperate.

Jason