Re: [PATCH] iommu/arm-smmu-v3: Fail aliasing StreamIDs more gracefully

[Jason Gunthorpe <jgg@nvidia.com>]

On Fri, Apr 11, 2025 at 03:50:10PM +0000, Pranjal Shrivastava wrote:

> > I can't think of a reason why we'd want any per-device failure to also
> > abort the whole iommu registration??
> 
> I don't think this change would abort the iommu registration?

Right, this patch causes iommu registration to succeed because the
only the ENODEV is ignored.

> The probe_iommu_group would simply ignore the -ENODEV. Or are you
> talking about a case where we don't return -ENODEV?

Yes, I mean the current situation the probe returns -EINVAL because
the SMMUv3 driver knows it controls the translation but cannot startup
the device due to the SID conflict.

> > It would be nice if the dev->iommu would record that the struct device
> > is inoperable and then we can fail
> > iommu_device_use_default_domain()/etc in a contained way.
> 
> Ohh okay.. you mean the dev->iommu_group == NULL may give an illusion to
> <bus>_dma_configure that DMA is allowed? 

Right, IMHO it is the different between ENODEV and Exxx. ENODEV
(ideally) means the iommu instance doesn't translate that device so it
has no information to add. EINVAL means the iommu instance does
translate and then we can be pretty sure DMA won't work since the
default STE is abort.

Thus, IMHO, the core code should ignore ENODEV and assume if no iommu
claims the device that it is identity. This is what we do today.

However EINVAL should disable future device drivers probing on the
broken struct device because most likely the DMA API won't work at
all.

> Even in that case the iommu would block the DMA right? And upon
> inspection of dmesg it would be clear that something went wrong with
> the probe?

Yes and yes. A better chance of the system booting if the iommu is
left registered and running with only some devices broken/disabled,
which is what was going on in v6.14

Jason