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

Jason Gunthorpe jgg at nvidia.com
Thu Feb 19 06:37:37 PST 2026


On Wed, Feb 18, 2026 at 02:56:35PM -0800, Nicolin Chen wrote:
> 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?

I don't think this blocking security work needs to be part of this
series. We just need to disable the mechanism for untrusted devices.

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

The ARM MSI aperture need is some special case here. Those drivers
don't use DMA at all so of course they don't have the DMA API setup,
but they do use the MSI aperture on ARM.

Broadly here we were talking about blocked domains for unattached
drivers, but an empty DMA domain is the same thing and still continues
to allow the MSI vectors to work.

So we can reframe this a little bit into more like

if the user requests IDENTITY then the IDENTITY domain is not
installed until just before the driver binds. Up until then it is in
the DMA domain. Meaning if userspace controls driver binding then
unbound drivers have their DMA access blocked by an empty DMA domain.

ie we dynamical shift modes for security.

This would only work on singleton groups.

Jason



More information about the linux-arm-kernel mailing list