Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices

[Nicolin Chen <nicolinc@nvidia.com>]

On Tue, Feb 03, 2026 at 01:55:40PM -0400, Jason Gunthorpe wrote:
> On Tue, Feb 03, 2026 at 09:45:17AM -0800, Nicolin Chen wrote:
> > Btw, attaching to IOMMU_DOMAIN_BLOCKED/group->blocking_domain is not
> > allowed in general if require_direct=true. I assume this case can be
> > an exception since there's no point in allowing a device that has no
> > driver yet to access any reserved region?
> 
> If require_direct is set then we have to disable this mechanism..

I found a corner case, which might be another exception here?

Most of dma_configure callback functions don't use default domain
when driver_managed_dma is set. And this breaks MSI on pcieports.

So, I am thinking of doing this:
	bool is_pci_bridge = dev_is_pci(dev) && pci_is_bridge(to_pci_dev(dev));
	[...]
	/*
	 * Block translation requests from a device not bound to a driver yet,
	 * with two exceptions:
	 *  1. IOMMU_RESV_DIRECT (require_direct) must guarantee that the
	 *     device always has access to reserved region(s)
	 *  2. PCI bridges (pcieport, CXL) skip default domain setup in its
	 *     dma_configure callback function due to !driver_managed_dma.
	 *     On the other hand, they require the default domain for MSIs.
	 */
	if (!dev->driver && !group->domain && !dev->iommu->require_direct &&
	    !is_pci_bridge) {
		ret = __iommu_group_alloc_blocking_domain(group);
		if (ret)
			goto err_remove_gdev;
		group->domain = group->blocking_domain;
	}

But I am very unsure about the other cases because it could lead
to some "regression" due to this new restriction.

That being said, setting driver_managed_dma while relying on the
default domain somewhat seems like a bug to me. So it feels that
we should fix those drivers instead of making an exception here?

Thanks
Nicolin