All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: iommu@lists.linux-foundation.org,
	LKML <linux-kernel@vger.kernel.org>,
	dmaengine@vger.kernel.org, Joerg Roedel <joro@8bytes.org>,
	David Woodhouse <dwmw2@infradead.org>,
	Jean-Philippe Brucker <jean-philippe@linaro.com>,
	Lu Baolu <baolu.lu@linux.intel.com>,
	vkoul@kernel.org, robin.murphy@arm.com, will@kernel.org,
	Yi Liu <yi.l.liu@intel.com>, Dave Jiang <dave.jiang@intel.com>,
	"Tian, Kevin" <kevin.tian@intel.com>,
	Raj Ashok <ashok.raj@intel.com>,
	Eric Auger <eric.auger@redhat.com>
Subject: Re: [PATCH v3 1/4] iommu/vt-d: Implement domain ops for attach_dev_pasid
Date: Tue, 10 May 2022 20:21:21 -0300	[thread overview]
Message-ID: <20220510232121.GP49344@nvidia.com> (raw)
In-Reply-To: <20220510210704.3539577-2-jacob.jun.pan@linux.intel.com>

On Tue, May 10, 2022 at 02:07:01PM -0700, Jacob Pan wrote:
> +static int intel_iommu_attach_dev_pasid(struct iommu_domain *domain,
> +					struct device *dev,
> +					ioasid_t pasid)
> +{
> +	struct device_domain_info *info = dev_iommu_priv_get(dev);
> +	struct dmar_domain *dmar_domain = to_dmar_domain(domain);
> +	struct intel_iommu *iommu = info->iommu;
> +	unsigned long flags;
> +	int ret = 0;
> +
> +	if (!sm_supported(iommu) || !info)
> +		return -ENODEV;
> +
> +	spin_lock_irqsave(&device_domain_lock, flags);
> +	/*
> +	 * If the same device already has a PASID attached, just return.
> +	 * DMA layer will return the PASID value to the caller.
> +	 */
> +	if (pasid != PASID_RID2PASID && info->pasid) {

Why check for PASID == 0 like this? Shouldn't pasid == 0 be rejected
as an invalid argument?

> +		if (info->pasid == pasid)
> +			ret = 0;

Doesn't this need to check that the current domain is the requested
domain as well? How can this happen anyhow - isn't it an error to
double attach?

> diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
> index 5af24befc9f1..55845a8c4f4d 100644
> +++ b/include/linux/intel-iommu.h
> @@ -627,6 +627,7 @@ struct device_domain_info {
>  	struct intel_iommu *iommu; /* IOMMU used by this device */
>  	struct dmar_domain *domain; /* pointer to domain */
>  	struct pasid_table *pasid_table; /* pasid table */
> +	ioasid_t pasid; /* DMA request with PASID */

And this seems wrong - the DMA API is not the only user of
attach_dev_pasid, so there should not be any global pasid for the
device.

I suspect this should be a counter of # of pasid domains attached so
that the special flush logic triggers

And rely on the core code to worry about assigning only one domain per
pasid - this should really be a 'set' function.

Jason

WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe via iommu <iommu@lists.linux-foundation.org>
To: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: vkoul@kernel.org, "Tian, Kevin" <kevin.tian@intel.com>,
	Dave Jiang <dave.jiang@intel.com>,
	Raj Ashok <ashok.raj@intel.com>,
	will@kernel.org, David Woodhouse <dwmw2@infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	iommu@lists.linux-foundation.org, dmaengine@vger.kernel.org,
	robin.murphy@arm.com,
	Jean-Philippe Brucker <jean-philippe@linaro.com>
Subject: Re: [PATCH v3 1/4] iommu/vt-d: Implement domain ops for attach_dev_pasid
Date: Tue, 10 May 2022 20:21:21 -0300	[thread overview]
Message-ID: <20220510232121.GP49344@nvidia.com> (raw)
In-Reply-To: <20220510210704.3539577-2-jacob.jun.pan@linux.intel.com>

On Tue, May 10, 2022 at 02:07:01PM -0700, Jacob Pan wrote:
> +static int intel_iommu_attach_dev_pasid(struct iommu_domain *domain,
> +					struct device *dev,
> +					ioasid_t pasid)
> +{
> +	struct device_domain_info *info = dev_iommu_priv_get(dev);
> +	struct dmar_domain *dmar_domain = to_dmar_domain(domain);
> +	struct intel_iommu *iommu = info->iommu;
> +	unsigned long flags;
> +	int ret = 0;
> +
> +	if (!sm_supported(iommu) || !info)
> +		return -ENODEV;
> +
> +	spin_lock_irqsave(&device_domain_lock, flags);
> +	/*
> +	 * If the same device already has a PASID attached, just return.
> +	 * DMA layer will return the PASID value to the caller.
> +	 */
> +	if (pasid != PASID_RID2PASID && info->pasid) {

Why check for PASID == 0 like this? Shouldn't pasid == 0 be rejected
as an invalid argument?

> +		if (info->pasid == pasid)
> +			ret = 0;

Doesn't this need to check that the current domain is the requested
domain as well? How can this happen anyhow - isn't it an error to
double attach?

> diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
> index 5af24befc9f1..55845a8c4f4d 100644
> +++ b/include/linux/intel-iommu.h
> @@ -627,6 +627,7 @@ struct device_domain_info {
>  	struct intel_iommu *iommu; /* IOMMU used by this device */
>  	struct dmar_domain *domain; /* pointer to domain */
>  	struct pasid_table *pasid_table; /* pasid table */
> +	ioasid_t pasid; /* DMA request with PASID */

And this seems wrong - the DMA API is not the only user of
attach_dev_pasid, so there should not be any global pasid for the
device.

I suspect this should be a counter of # of pasid domains attached so
that the special flush logic triggers

And rely on the core code to worry about assigning only one domain per
pasid - this should really be a 'set' function.

Jason
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2022-05-10 23:21 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-10 21:07 [PATCH v3 0/4] Enable PASID for DMA API users Jacob Pan
2022-05-10 21:07 ` Jacob Pan
2022-05-10 21:07 ` [PATCH v3 1/4] iommu/vt-d: Implement domain ops for attach_dev_pasid Jacob Pan
2022-05-10 21:07   ` Jacob Pan
2022-05-10 23:21   ` Jason Gunthorpe [this message]
2022-05-10 23:21     ` Jason Gunthorpe via iommu
2022-05-11  0:23     ` Jacob Pan
2022-05-11  0:23       ` Jacob Pan
2022-05-11 11:54       ` Jason Gunthorpe
2022-05-11 11:54         ` Jason Gunthorpe via iommu
2022-05-11 15:35         ` Jacob Pan
2022-05-11 15:35           ` Jacob Pan
2022-05-11 16:12           ` Jason Gunthorpe
2022-05-11 16:12             ` Jason Gunthorpe via iommu
2022-05-11 17:02             ` Jacob Pan
2022-05-11 17:02               ` Jacob Pan
2022-05-11 17:00               ` Jason Gunthorpe
2022-05-11 17:00                 ` Jason Gunthorpe via iommu
2022-05-11 17:25                 ` Jacob Pan
2022-05-11 17:25                   ` Jacob Pan
2022-05-11 18:29                   ` Jason Gunthorpe
2022-05-11 18:29                     ` Jason Gunthorpe via iommu
2022-05-18 18:42                     ` Jacob Pan
2022-05-18 18:42                       ` Jacob Pan
2022-05-18 18:52                       ` Jason Gunthorpe
2022-05-18 18:52                         ` Jason Gunthorpe via iommu
2022-05-19 21:05                         ` Jacob Pan
2022-05-19 21:05                           ` Jacob Pan
2022-05-12  1:16                   ` Baolu Lu
2022-05-12  1:16                     ` Baolu Lu
2022-05-12  6:22                 ` Baolu Lu
2022-05-12  6:22                   ` Baolu Lu
2022-05-12 11:52                   ` Jason Gunthorpe
2022-05-12 11:52                     ` Jason Gunthorpe via iommu
2022-05-10 21:07 ` [PATCH v3 2/4] iommu: Add PASID support for DMA mapping API users Jacob Pan
2022-05-10 21:07   ` Jacob Pan
2022-05-10 23:28   ` Jason Gunthorpe
2022-05-10 23:28     ` Jason Gunthorpe via iommu
2022-05-11  0:43     ` Jacob Pan
2022-05-11  0:43       ` Jacob Pan
2022-05-10 21:07 ` [PATCH v3 3/4] dmaengine: idxd: Use DMA API for in-kernel DMA with PASID Jacob Pan
2022-05-10 21:07   ` Jacob Pan
2022-05-10 21:07 ` [PATCH v3 4/4] iommu/vt-d: Delete unused SVM flag Jacob Pan
2022-05-10 21:07   ` Jacob Pan

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=20220510232121.GP49344@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=ashok.raj@intel.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=dave.jiang@intel.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=dwmw2@infradead.org \
    --cc=eric.auger@redhat.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jacob.jun.pan@linux.intel.com \
    --cc=jean-philippe@linaro.com \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=vkoul@kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.