From: Jacob Pan <jacob.jun.pan@linux.intel.com>
To: Jason Gunthorpe <jgg@nvidia.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>,
jacob.jun.pan@linux.intel.com
Subject: Re: [PATCH v3 1/4] iommu/vt-d: Implement domain ops for attach_dev_pasid
Date: Tue, 10 May 2022 17:23:09 -0700 [thread overview]
Message-ID: <20220510172309.3c4e7512@jacob-builder> (raw)
In-Reply-To: <20220510232121.GP49344@nvidia.com>
Hi Jason,
On Tue, 10 May 2022 20:21:21 -0300, Jason Gunthorpe <jgg@nvidia.com> wrote:
> 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?
Right, I was planning on reuse the attach function for RIDPASID as clean
up, but didn't include here. Will fix.
>
> > + 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.
>
True but the attach_dev_pasid() op is domain type specific. i.e. DMA API
has its own attach_dev_pasid which is different than sva domain
attach_dev_pasid().
device_domain_info is only used by DMA API.
> I suspect this should be a counter of # of pasid domains attached so
> that the special flush logic triggers
>
This field is only used for devTLB, so it is per domain-device. struct
device_domain_info is allocated per device-domain as well. Sorry, I might
have totally missed your point.
> And rely on the core code to worry about assigning only one domain per
> pasid - this should really be a 'set' function.
>
Yes, in this set the core code (in dma-iommu.c) only assign one PASID per
DMA domain type.
Are you suggesting the dma-iommu API should be called
iommu_set_dma_pasid instead of iommu_attach_dma_pasid?
Thanks a lot for the quick review!
Jacob
WARNING: multiple messages have this Message-ID (diff)
From: Jacob Pan <jacob.jun.pan@linux.intel.com>
To: Jason Gunthorpe <jgg@nvidia.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 17:23:09 -0700 [thread overview]
Message-ID: <20220510172309.3c4e7512@jacob-builder> (raw)
In-Reply-To: <20220510232121.GP49344@nvidia.com>
Hi Jason,
On Tue, 10 May 2022 20:21:21 -0300, Jason Gunthorpe <jgg@nvidia.com> wrote:
> 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?
Right, I was planning on reuse the attach function for RIDPASID as clean
up, but didn't include here. Will fix.
>
> > + 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.
>
True but the attach_dev_pasid() op is domain type specific. i.e. DMA API
has its own attach_dev_pasid which is different than sva domain
attach_dev_pasid().
device_domain_info is only used by DMA API.
> I suspect this should be a counter of # of pasid domains attached so
> that the special flush logic triggers
>
This field is only used for devTLB, so it is per domain-device. struct
device_domain_info is allocated per device-domain as well. Sorry, I might
have totally missed your point.
> And rely on the core code to worry about assigning only one domain per
> pasid - this should really be a 'set' function.
>
Yes, in this set the core code (in dma-iommu.c) only assign one PASID per
DMA domain type.
Are you suggesting the dma-iommu API should be called
iommu_set_dma_pasid instead of iommu_attach_dma_pasid?
Thanks a lot for the quick review!
Jacob
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2022-05-11 0:19 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
2022-05-10 23:21 ` Jason Gunthorpe via iommu
2022-05-11 0:23 ` Jacob Pan [this message]
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=20220510172309.3c4e7512@jacob-builder \
--to=jacob.jun.pan@linux.intel.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=jean-philippe@linaro.com \
--cc=jgg@nvidia.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.