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

[Tian, Kevin]

> From: Williams, Dan J <dan.j.williams at intel.com>
> Sent: Friday, January 23, 2026 3:46 AM
> 
> Jason Gunthorpe wrote:
> > On Wed, Jan 21, 2026 at 09:44:32PM -0800, dan.j.williams at intel.com
> wrote:
> > > I do not immediately see what is wrong with requiring userspace policy
> > > opt-in. That naturally gets replaced by installing the device's
> > > certificate (for native PCI CMA), authenticating the device with the
> > > TSM (for PCI IDE), or obviated by secure-ATS if that arrives.
> >
> > I think that goes back to the discussion about not loading drivers
> > before validating the device.
> >
> > It would also make alot of sense to leave the IOMMU blocking until the
> > driver is loaded for these secure situations. The blocking translation
> > should block ATS too.
> >
> > Then the flow you are describing will work well:
> >
> > 1) At pre-boot the IOMMU will block all DMA including Translated.
> > 2) The OS activates the IOMMU driver and keeps blocking.
> > 3) Instead of immediately binding a default domain the IOMMU core
> >    leaves the translation blocking.
> > 4) The OS defers loading the driver to userspace.
> > 5) Userspace measures the device and "accepts" it by loading the
> >    driver
> > 6) IOMMU core attaches a non-blocking default domain and activates ATS
> 
> That works for me. Give the paranoid the ability to have a point where they
> can
> be assured that the shields were not lowered prematurely.

Jason described the flow as "for these secure situations", i.e. not a general
requirement for cxl.cache, but iiuc Dan may instead want userspace policy
opt-in to be default (and with CMA/TSM etc. it gets easier)?

Better to clarity the agreement here as the output decides whether to
continue what this series tries to do...

At a glance cxl.cache devices have gained ATS enabled automatically in
most cases (same as for all other ats-capable PCI devices):

- ARM: ATS is enabled automatically when attaching the default domain
  to the device in certain configurations, and this series tries to auto
  enable it in a missing configuration

- AMD: ATS is enabled at domain attach time

- Intel: ATS is enabled when a device is probed by intel-iommu driver
  (incompatible with the suggested flow)

Given above already shipped in distributions, probably we have to keep
them for compatibility (implying this series makes sense to fix a gap
in existing policy), then treat the suggested flow as an enhancement
for future?