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

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, Jan 27, 2026 at 08:10:06AM +0000, Tian, Kevin wrote:
> > From: Williams, Dan J <dan.j.williams@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@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)?

I think the general strategy has been to push userspace to do security
decisions before binding drivers. So we have a plan for confidential
compute VMs, and if there is interest then we can probably re-use that
plan in all other cases.

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

Yes.
 
> - 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

Yes, ARM took the position that ATS should be left disabled for
IDENTITY both because of SMMU constraints and also because it made
some sense that you wouldn't want ATS overhead just to get a 1:1
translation.

> - AMD: ATS is enabled at domain attach time

I'd argue this is an error and it should work like ARM

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

This is definately not a good choice :)

IMHO it is security required that the IOMMU driver block Translated
requests while a BLOCKED domain is attached, and while the IOMMU is
refusing ATS then device's ATS enable should be disabled.

> 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?

I don't think we have a compatability issue here, just a security
one.

Drivers need to ensure that ATS is disabled at PCI and Translated
requestes blocked in IOMMU HW while a BLOCKED domain is attached.

Drivers can choose if they want to enable ATS for IDENTITY or not,
(recommend not for performance and consistency).

Jason