[PATCH v6 3/3] iommu/arm-smmu-v3: Allow ATS to be always on

Jason Gunthorpe jgg at nvidia.com
Thu May 28 13:04:50 PDT 2026


On Thu, May 28, 2026 at 11:20:35AM -0700, Nicolin Chen wrote:
> On Thu, May 28, 2026 at 06:14:57PM +0000, Pranjal Shrivastava wrote:
> > On Thu, May 28, 2026 at 03:00:18PM -0300, Jason Gunthorpe wrote:
> > > On Thu, May 28, 2026 at 04:32:23PM +0000, Pranjal Shrivastava wrote:
> > > > On Thu, May 28, 2026 at 12:29:30PM -0300, Jason Gunthorpe wrote:
> > > > > On Thu, May 28, 2026 at 03:24:40PM +0000, Pranjal Shrivastava wrote:
> > > > > 
> > > > > > > +	master->ats_always_on = true;
> > > > > > > +
> > > > > > > +	return arm_smmu_alloc_cd_tables(master);
> > > > > > 
> > > > > > Nit: I'm not sure if I'm getting this right, are we saying we *need* to
> > > > > > allocate CDs for CXL.cache cases in the probe itself because STE.EATS
> > > > > > requires Config=Translate with S1DSS in bypass?
> > > > > 
> > > > > Yeah, basically.
> > > > > 
> > > > > Effectively the ARM rules for enabling ATS and Bypass together require
> > > > > a valid CD table pointer.
> > > > 
> > > > Ack. But do we expect transactions before attach_dev? What'd happen if
> > > > we don't allocate CDs here?
> > > 
> > > It can be done at any point before a non-abort STE is formed.
> > > 
> > > The core code pretty much does this immediately after probe so there
> > > isn't much point in moving it later.
> > > 
> > 
> > Right.. that's what I'm not understanding clearly, if the STE is Abort
> > anyway during probe, why are we breaking the alloc-at-attach convention? 
> > Usually, we allocate CD tables in the first attach_dev call. Why does
> > that not work here?
> 
> It would work in attach_dev(). I just felt cleaner to have it in
> probe(), paired with arm_smmu_free_cd_tables() in the release().

I thought it was like this because we don't have an alloc on attach
flow for the identity domain, so add it there or add it here..

Jason



More information about the linux-arm-kernel mailing list