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

[Robin Murphy]

On 2026-02-20 12:50 pm, Jason Gunthorpe wrote:
> On Thu, Feb 19, 2026 at 08:52:56PM -0800, Nicolin Chen wrote:
>>> 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?
> 
> The objective of this security step is to keep ATS blocked and
> IDENTITY domains disabled until the userspace has "accepted" the
> device by binding a driver to it.
> 
> The off the cuff suggestion was to just park the device BLOCKED until
> a driver is bound. This disables ATS and blocks translation.
> 
> That doesn't work on ARM because of the MSI issue.

But is that an issue? Until the device has a driver, surely it shouldn't 
be expected to send interrupts at all, much less depend on them being 
received and understood by Linux? The MSI cookie is only populated once 
a driver actually requests some MSI vectors (since it doesn't know what 
ITS address(es) may or may not need mapping), so an empty DMA domain is 
still no better than a true blocking domain in this regard anyway.

Thanks,
Robin.

> The next suggestion is to park the device in a real DMA domain with an
> actual page table and DMA API hooked up. Now interrupts will work and
> the domain is empty so there is no translation. The issue here is the
> domain doesn't block ATS. We could fix this with some "disable ATS"
> domain flag.
> 
> In either case when the driver is bound and requests that the DMA API
> start working if the user requested IDENTITY then it has to be
> switched away from the parked domain to IDENTITY.
> 
> A final thought would be to change around the driver managed DMA
> mechanism a bit to allow drivers to indicate they use IRQs but not
> DMA, then the bind step could switch from a BLOCKED domain to an empty
> DMA API domain to allow MSI to work.
> 
> Jason