RE: [PATCH v3 4/5] iommu: Introduce iommu_dev_reset_prepare() and iommu_dev_reset_done()

Tian, Kevin
2025-08-15T09:14:33Z

> From: Nicolin Chen <nicolinc@nvidia.com>
> Sent: Tuesday, August 12, 2025 6:59 AM
>
[...]
> However, if there is a domain attachment/replacement happening during an
> ongoing reset, ATS routines may be re-activated between the two function
> calls. So, introduce a new pending_reset flag in group_device to defer an
> attachment during a reset, allowing iommu core to cache target domains in
> the SW level while bypassing the driver. The iommu_dev_reset_done() will
> re-attach these soft-attached domains, once the device reset is finished.

attach could fail e.g. when device and domain are incompatible. This
deferred attach (until reset done) makes compatibility check impossible in
the resetting window, given the driver attach_dev callback is not called
in the normal attach path.

Worse..

> + /* Shift RID domain back to group->domain */
> + if (group->domain != group->blocking_domain)
> + WARN_ON(__iommu_attach_device(group->domain, dev));

..means that an user could trigger WARN_ON() easily if he knows an attach
would fail.

IMHO we may just fail attach request in the resetting window then
WARN_ON above makes sense as it's shifting back to a domain which was
originally attached to the resetting device.

Not sure any valid case where one would want to attach/replace domain
for a resetting device...