Re: [PATCH v3 4/5] iommu/hyperv: Add para-virtualized IOMMU support for Hyper-V guest

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
>