On Thu, Aug 13, 2026 at 07:46:27PM -0300, Jason Gunthorpe wrote:
> On Thu, Aug 13, 2026 at 03:29:13PM -0700, Jacob Pan wrote:
>
> > > +static int hv_iommu_blocking_attach_dev(struct iommu_domain *domain,
> > > + struct device *dev,
> > > + struct iommu_domain *old)
> > > +{
> > > + struct hv_iommu_endpoint *vdev = dev_iommu_priv_get(dev);
> > > + struct hv_iommu_domain *hv_domain =
> > > to_hv_iommu_domain(domain);
> > > + struct pci_dev *pdev = to_pci_dev(dev);
> > > + int ret;
> > > +
> > > + if (pdev->ats_enabled)
> > > + pci_disable_ats(pdev);
> > > +
> > > + if (vdev->hv_domain == hv_domain)
> > > + return 0;
> > It may not be needed since the core code will check this. If you keep
> > this as extra precaution, should this be moved up before ats? since ats
> > must be disabled already if blocking domain is attached.
@Jacob In v2
(https://lore.kernel.org/all/[email protected]/),
this check was in the common attach helper. It was redundant because the normal
group domain path already skips same-domain attaches.
In this version, I removed it from the common helper and kept it only in the
blocking attach callback. iommu_deinit_device() directly attaches the
device to release_domain without going through the group-level check.
IIUC, for a device which is alreading parked in the blocking domain, the
releasing might invoke another blocking-domain attach.
Sorry, I should have explained this change and its rationale in the changelog.
>
> Why check it at all? Is there an issue with attaching the same thing
> twice? Will it blip the DMA or something?
Actually, I do not think there should be any issue with attaching twice.
Hyper-V *should* be able to accept such attachment. But I do not want to
make such assumption just for a redundant hypercall.
Does this reasoning make sense, or would you prefer that I remove the
check?
B.R.
Yu
>
> Jason
>
