public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Lu Baolu <baolu.lu@linux.intel.com>
Cc: Joerg Roedel <joro@8bytes.org>,
	Christoph Hellwig <hch@infradead.org>,
	Ben Skeggs <bskeggs@redhat.com>,
	Kevin Tian <kevin.tian@intel.com>,
	Ashok Raj <ashok.raj@intel.com>, Will Deacon <will@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Eric Auger <eric.auger@redhat.com>, Liu Yi L <yi.l.liu@intel.com>,
	Jacob jun Pan <jacob.jun.pan@intel.com>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	Thierry Reding <thierry.reding@gmail.com>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 09/10] iommu: Use dev_iommu_ops() helper
Date: Wed, 9 Feb 2022 09:41:52 -0400	[thread overview]
Message-ID: <20220209134152.GA4160@nvidia.com> (raw)
In-Reply-To: <20220208012559.1121729-10-baolu.lu@linux.intel.com>

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?

>  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.

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.

> @@ -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?

Jason

  parent reply	other threads:[~2022-02-09 13:41 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-08  1:25 [PATCH v2 00/10] iommu cleanup and refactoring Lu Baolu
2022-02-08  1:25 ` [PATCH v2 01/10] iommu/vt-d: Remove guest pasid related callbacks Lu Baolu
2022-02-09 13:29   ` Jason Gunthorpe
2022-02-08  1:25 ` [PATCH v2 02/10] iommu: Remove guest pasid related interfaces and definitions Lu Baolu
2022-02-09 13:29   ` Jason Gunthorpe
2022-02-10  0:44     ` Lu Baolu
2022-02-08  1:25 ` [PATCH v2 03/10] iommu/vt-d: Remove aux-domain related callbacks Lu Baolu
2022-02-09 13:30   ` Jason Gunthorpe
2022-02-08  1:25 ` [PATCH v2 04/10] iommu: Remove aux-domain related interfaces and iommu_ops Lu Baolu
2022-02-09 13:30   ` Jason Gunthorpe
2022-02-08  1:25 ` [PATCH v2 05/10] iommu: Remove apply_resv_region Lu Baolu
2022-02-09  6:36   ` Christoph Hellwig
2022-02-09 13:31   ` Jason Gunthorpe
2022-02-08  1:25 ` [PATCH v2 06/10] drm/nouveau/device: Get right pgsize_bitmap of iommu_domain Lu Baolu
2022-02-09 13:31   ` Jason Gunthorpe
2022-02-10  0:48     ` Lu Baolu
2022-02-08  1:25 ` [PATCH v2 07/10] iommu: Use right way to retrieve iommu_ops Lu Baolu
2022-02-09  6:40   ` Christoph Hellwig
2022-02-09 13:33   ` Jason Gunthorpe
2022-02-08  1:25 ` [PATCH v2 08/10] iommu: Remove unused argument in is_attach_deferred Lu Baolu
2022-02-09  6:41   ` Christoph Hellwig
2022-02-09 13:34   ` Jason Gunthorpe
2022-02-09 13:52   ` Robin Murphy
2022-02-10  0:51     ` Lu Baolu
2022-02-14  0:50     ` Lu Baolu
2022-02-08  1:25 ` [PATCH v2 09/10] iommu: Use dev_iommu_ops() helper Lu Baolu
2022-02-09  6:44   ` Christoph Hellwig
2022-02-09 13:41   ` Jason Gunthorpe [this message]
2022-02-10  1:10     ` Lu Baolu
2022-02-08  1:25 ` [PATCH v2 10/10] iommu: Split struct iommu_ops Lu Baolu
2022-02-09  6:46   ` Christoph Hellwig
2022-02-09 13:43     ` Jason Gunthorpe
2022-02-14  2:00 ` [PATCH v2 00/10] iommu cleanup and refactoring Lu Baolu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220209134152.GA4160@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=airlied@linux.ie \
    --cc=alex.williamson@redhat.com \
    --cc=ashok.raj@intel.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=bskeggs@redhat.com \
    --cc=daniel@ffwll.ch \
    --cc=eric.auger@redhat.com \
    --cc=hch@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jacob.jun.pan@intel.com \
    --cc=jonathanh@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=thierry.reding@gmail.com \
    --cc=will@kernel.org \
    --cc=yi.l.liu@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox