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

[Nicolin Chen]

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?

Thanks
Nicolin