Re: [PATCH v2 09/10] iommu: Use dev_iommu_ops() helper

Lu Baolu
2022-02-10T01:27:32Z

On 2/9/22 9:41 PM, Jason Gunthorpe wrote:
> On Tue, Feb 08, 2022 at 09:25:58AM +0800, Lu Baolu wrote:
>> Convert all the feasible instances of dev->bus->iommu_ops to
>> dev_iommu_ops() in order to making the operation of obtaining
>> iommu_ops from a device consistent.
>
> Why are there two patches doing this conversion? Roll this into the
> prior patch?

It's reasonable to merge this patch into the previous one where
dev_iommu_ops() was added.

>
>> void iommu_get_resv_regions(struct device *dev, struct list_head *list)
>> {
>> - const struct iommu_ops *ops = dev->bus->iommu_ops;
>> + const struct iommu_ops *ops = dev_iommu_ops(dev);
>>
>> if (ops && ops->get_resv_regions)
>> ops->get_resv_regions(dev, list);
>
> And agree with Christoph, don't keep confusing ops null tests -
> dev_iommu_ops() never returns null and any function using it must rely
> on the caller to handle this, somehow.

Agree with you both.

>
> However, I wonder how safe this is. Certainly some APIs like this one
> it is fine, but I would be happier if the 'first' APIs like
> bind/attach/alloc/etc fail silently upwards. In many cases these APIs
> are called based on things like DT configuration, or VFIO or
> something, and the caller is expecting the iommu layer to do all
> necessary validation.

domain_alloc()/bind/unbind/attach/detach/etc are APIs for external
kernel components. We shouldn't use dev_iommu_ops() there and all
necessary validation should be done.

The dev_iommu_ops() are for IOMMU subsystem internal use purpose, hence
we can add a WARN there and avoid further checks.

>
>> @@ -2788,7 +2789,7 @@ iommu_sva_bind_device(struct device *dev, struct mm_struct *mm, void *drvdata)
>> {
>> struct iommu_group *group;
>> struct iommu_sva *handle = ERR_PTR(-EINVAL);
>> - const struct iommu_ops *ops = dev->bus->iommu_ops;
>> + const struct iommu_ops *ops = dev_iommu_ops(dev);
>>
>> if (!ops || !ops->sva_bind)
>> return ERR_PTR(-ENODEV);
>> @@ -2831,7 +2832,7 @@ void iommu_sva_unbind_device(struct iommu_sva *handle)
>> {
>> struct iommu_group *group;
>> struct device *dev = handle->dev;
>> - const struct iommu_ops *ops = dev->bus->iommu_ops;
>> + const struct iommu_ops *ops = dev_iommu_ops(dev);
>>
>> if (!ops || !ops->sva_unbind)
>> return;
>> @@ -2850,7 +2851,7 @@ EXPORT_SYMBOL_GPL(iommu_sva_unbind_device);
>>
>> u32 iommu_sva_get_pasid(struct iommu_sva *handle)
>> {
>> - const struct iommu_ops *ops = handle->dev->bus->iommu_ops;
>> + const struct iommu_ops *ops = dev_iommu_ops(handle->dev);
>>
>> if (!ops || !ops->sva_get_pasid)
>> return IOMMU_PASID_INVALID;
>
> We all agreed that this sva object will turn into a domain and thus
> all of this will eventually move to domain ops?

Partially yes.

My plan is to leverage the sva-domain specific .attach/detach_dev_pasid
callbacks. All the sva related ops in iommu_ops could be removed.

>
> Jason

Best regards,
baolu