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

Jason Gunthorpe
2023-04-20T15:00:00Z

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