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

Nicolin Chen
2026-03-31T12:23:53Z

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