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

Nicolin Chen
2026-02-18T22:57:10Z

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