Re: [PATCH rc v2] iommu: Fix nested pci_dev_reset_iommu_prepare/done()

[Nicolin Chen <nicolinc@nvidia.com>]

On Tue, Mar 31, 2026 at 07:12:19AM +0000, Tian, Kevin wrote:
> > > > >   - prepare() only detaches the specific pdev, leaving other
> > > > >     devices in the group still attached to the original domain
> > >
> > > no, attach is per-group. all devices are changed together.
> > 
> > I think prepare() should use the per-device ops:
> >     ops->attach_dev (via __iommu_attach_device)
> >     ops->set_dev_pasid
> > right?
> 
> it's per-device op but the condition of calling it is per-group:
> 
>         if (group->domain != group->blocking_domain) {
>                 ret = __iommu_attach_device(group->blocking_domain, &pdev->dev,
>                                             group->domain);
>                 if (ret)
>                         return ret;
>         }

If the group->domain is not blocking_domain, this device will
move away from group->domain to blocking_domain, while other
device (in the same group) are staying in group->domain. No?

> > And it is intended to limit to the resetting device only. Other
> > devices in the group can still stay in the attached domain, but
> > they cannot do new attachment (-EBUSY) because that's per-group.
> 
> how could other devices stay in the attached domain?

We call __iommu_attach_device only on one gdev, not looping
the entire group, right?

> > Since prepare() is per-device, the per-group reset_cnt wouldn't
> > be sufficient if one device is resetting while the other isn't.
> > 
> > iommu_driver_get_domain_for_dev() for example would return the
> > blocking_domain for both devices, but physically only the first
> > device is attached to blocking_domain.
> 
> what do you mean by 'physically'?

I mean SMMU driver will program STE to ask SMMU HW to reflect
the change "physically". But it won't program the other STEs.

Nicolin