[PATCH v2 8/8] iommu/arm-smmu-v3: Support the DS expansion of RIL's SCALE

Jason Gunthorpe jgg at nvidia.com
Wed Jul 8 06:05:29 PDT 2026


On Tue, Jul 07, 2026 at 07:10:37PM -0700, Nicolin Chen wrote:
> On Tue, Jul 07, 2026 at 09:02:39PM -0300, Jason Gunthorpe wrote:
> > On Tue, Jul 07, 2026 at 04:20:58PM -0700, Nicolin Chen wrote:
> > > On Mon, Jul 06, 2026 at 01:26:45PM -0300, Jason Gunthorpe wrote:
> > > > If DS is supported then SCALE can go up to 39. Detect the IDR and compute
> > > > a scale max that is compatible for the entire invs list.
> > > > 
> > > > Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
> > > 
> > > Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>
> > > 
> > > > @@ -5235,6 +5242,9 @@ static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu)
> > > >  	/* Maximum number of outstanding stalls */
> > > >  	smmu->evtq.max_stalls = FIELD_GET(IDR5_STALL_MAX, reg);
> > > >  
> > > > +	if (reg & IDR5_DS)
> > > > +		smmu->features |= ARM_SMMU_FEAT_DS;
> > > > +
> > > 
> > > Just a note here:
> > > 
> > > This somehow conflicts with my iommufd_invalidation_loop series
> > > where we sanitize user space commands, because the driver would
> > > support IDR5.DS. So, one of the series would need a rebase.
> > 
> > Oh that's an interesting one. So if you add strict validation it will
> > technically break DS, no VMM can set DS to the vIOMMU as then it would
> > face invalid SCALE which the kernel will now block.
> > 
> > Maybe these hunks need to be included in your series, I do expect it
> > to go first, and we should try to validate fully.
> 
> OK. I can take the minimal DS part into my series.
> 
> One more question to confirm: there are other fields like DS, which
> are defined in the spec but not supported by the driver. Should we
> expose them via hw_info while rejecting them via user cmds?

Yeah, we decided long ago to expose all the IDR as-is. Userspace needs
to understand what the conditions are for including a feature in the
VIOMMU.

Something like DS could have reasonably been concluded that the IDR is
sufficient since kernel always supported it since iommufd support
came.

Some things will probably need kernel flags to indicate the support
is there

Other things might just work out of the box (like a PTE or CD
feature).

Jason



More information about the linux-arm-kernel mailing list