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

[Nicolin Chen]

On Thu, Feb 19, 2026 at 01:41:39PM -0400, Jason Gunthorpe wrote:
> On Thu, Feb 19, 2026 at 08:53:19AM -0800, Nicolin Chen wrote:
> > The thing is that those driver_managed_dma callbacks don't call
> > iommu_device_use_default_domain(). So, the iommu core loses the
> > trigger to switch domain from BLOCKED/empty-DMA to DMA/IDENTITY.
> 
> But they don't use DMA API at all so it doesn't matter to them.
> 
> Your issue is that BLOCKED breaks MSI on ARM.

Thanks for the hint!

It actually failed in iommu_dma_prepare_msi() due to having an
IOMMU_COOKIE_NONE in the blocking_domain.

My implementation sets group->domain to group->blocking_domain,
and keeps group->default_domain=NULL to retain the EPROBE_DEFER
validation in iommu_device_use_default_domain().

Then in iommu_dma_prepare_msi(), the group->domain now becomes
valid so it failed due to its unsupported iommu cookie, which
I entirely missed.

I could simply fix this by adding:

@@ -3892,7 +3892,8 @@ int iommu_dma_prepare_msi(struct msi_desc *desc, phys_addr_t msi_addr)

        mutex_lock(&group->mutex);
        /* An IDENTITY domain must pass through */
-       if (group->domain && group->domain->type != IOMMU_DOMAIN_IDENTITY) {
+       if (group->default_domain && group->domain &&
+           group->domain->type != IOMMU_DOMAIN_IDENTITY) {
                switch (group->domain->cookie_type) {
                case IOMMU_COOKIE_DMA_MSI:
                case IOMMU_COOKIE_DMA_IOVA:

> That is fixed by using
> an empty-DMA API domain as default.

Hmm, even if we set arm_smmu_blocked_domain.type to an empty DMA
(IOMMU_DOMAIN_UNMANAGED?), it still doesn't allocate a cookie?

> What is missing is to bring back the IDENTITY performance optimization
> in a secure way.

I might have got it wrong (from the last part below).
https://lore.kernel.org/linux-iommu/20260127150440.GF1134360@nvidia.com/.

You mean to disable ATS on IDENTITY domains? 

Thanks
Nicolin