From: Lu Baolu <baolu.lu@linux.intel.com>
To: "Tian, Kevin" <kevin.tian@intel.com>,
Joerg Roedel <joro@8bytes.org>, Jason Gunthorpe <jgg@nvidia.com>,
Christoph Hellwig <hch@infradead.org>,
"Raj, Ashok" <ashok.raj@intel.com>, Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Jean-Philippe Brucker <jean-philippe@linaro.com>
Cc: baolu.lu@linux.intel.com, Eric Auger <eric.auger@redhat.com>,
"Liu, Yi L" <yi.l.liu@intel.com>,
"Pan, Jacob jun" <jacob.jun.pan@intel.com>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFC v3 08/12] iommu/sva: Use attach/detach_pasid_dev in SVA interfaces
Date: Tue, 12 Apr 2022 20:53:11 +0800 [thread overview]
Message-ID: <1289f780-143e-004c-41ac-d95b6f18d63c@linux.intel.com> (raw)
In-Reply-To: <BN9PR11MB5276BCAA64597FE400DF15CF8CED9@BN9PR11MB5276.namprd11.prod.outlook.com>
On 2022/4/12 15:19, Tian, Kevin wrote:
>> From: Lu Baolu <baolu.lu@linux.intel.com>
>> Sent: Sunday, April 10, 2022 6:25 PM
>> +struct iommu_sva *
>> +iommu_sva_bind_device(struct device *dev, struct mm_struct *mm, void
>> *drvdata)
>> +{
>> + int ret = -EINVAL;
>> + struct iommu_sva *handle;
>> + struct iommu_domain *domain;
>> + struct iommu_sva_ioas *ioas;
>> +
>> + /*
>> + * TODO: Remove the drvdata parameter after kernel PASID support
>> is
>> + * enabled for the idxd driver.
>> + */
>> + if (drvdata)
>> + return ERR_PTR(-EOPNOTSUPP);
>> +
>> + /* Allocate mm->pasid if necessary. */
>> + ret = iommu_sva_alloc_pasid(mm, 1, (1U << dev->iommu->pasid_bits)
>> - 1);
>> + if (ret)
>> + return ERR_PTR(ret);
>> +
>> + mutex_lock(&iommu_sva_lock);
>> + ioas = iommu_sva_ioas_get(mm, mm->pasid);
>> + if (!ioas) {
>> + ret = -ENOMEM;
>
> ioas can be NULL for multiple reasons, e.g. :
>
> 1) ioas->mm != mm;
> 2) kzalloc failure;
> 3) xa_store failure;
>
> It's more sensible to return error from iommu_sva_ioas_get() directly.
Fair enough.
>
>> + goto out_unlock;
>> + }
>> +
>> + /* Search for an existing bond. */
>> + list_for_each_entry(handle, &ioas->bonds, node) {
>> + if (handle->dev == dev) {
>> + refcount_inc(&handle->users);
>> + /* No new bond, drop the counter. */
>> + iommu_sva_ioas_put(ioas);
>> + goto out_success;
>> + }
>> + }
>> +
>> + handle = kzalloc(sizeof(*handle), GFP_KERNEL);
>
> s/handle/bond/?
"handle" is used in the previous implementation but "bond" looks better
to read. :-)
>
>> + if (!handle) {
>> + ret = -ENOMEM;
>> + goto out_put_ioas;
>> + }
>> +
>> + /* The reference to ioas will be kept until domain free. */
>> + domain = iommu_sva_alloc_domain(dev, ioas);
>
> Shouldn't we first try whether existing domains are compatible to this
> device?
If we think that here domain represents a hardware pagetable actually
used by IOMMU for a {device, pasid}, we are able to use per-{device,
pasid} domain without checking compatibility. Sharing a domain among
devices under the same IOMMU may be an optimization. That could be done
in the IOMMU driver just like what vt-d driver is doing for pass-through
DMA domains.
>
>> @@ -1952,6 +1954,7 @@ EXPORT_SYMBOL_GPL(iommu_domain_alloc);
>> void iommu_domain_free(struct iommu_domain *domain)
>> {
>> iommu_put_dma_cookie(domain);
>> + iommu_sva_ioas_put(domain->sva_ioas);
>> domain->ops->free(domain);
>> }
>
> is it good to have general iommu_domain_free() to always call a put()
> function for a specific domain type? Why cannot it be done before
> calling iommu_domain_free() in sva-lib.c?
It's better to have a generic free() helper since an sva domain could be
freed outside of iommu sva code as you can see in the following patches.
Best regards,
baolu
next prev parent reply other threads:[~2022-04-12 13:09 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-10 10:24 [PATCH RFC v3 00/12] iommu: SVA and IOPF refactoring Lu Baolu
2022-04-10 10:24 ` [PATCH RFC v3 01/12] iommu: Add pasid_bits field in struct dev_iommu Lu Baolu
2022-04-10 10:24 ` [PATCH RFC v3 02/12] iommu: Add a flag to indicate immutable singleton group Lu Baolu
2022-04-12 3:15 ` Tian, Kevin
2022-04-12 5:08 ` Lu Baolu
2022-04-12 6:34 ` Yi Liu
2022-04-12 11:56 ` Lu Baolu
2022-04-12 7:37 ` Tian, Kevin
2022-04-12 13:02 ` Lu Baolu
2022-04-12 23:32 ` Tian, Kevin
2022-04-13 12:02 ` Lu Baolu
2022-04-12 7:39 ` Tian, Kevin
2022-04-12 13:10 ` Lu Baolu
2022-04-10 10:24 ` [PATCH RFC v3 03/12] iommu: Add attach/detach_dev_pasid domain ops Lu Baolu
2022-04-10 10:24 ` [PATCH RFC v3 04/12] iommu/sva: Basic data structures for SVA Lu Baolu
2022-04-12 6:49 ` Tian, Kevin
2022-04-12 11:58 ` Lu Baolu
2022-04-12 6:56 ` Tian, Kevin
2022-04-12 12:08 ` Lu Baolu
2022-04-10 10:24 ` [PATCH RFC v3 05/12] iommu/vt-d: Remove SVM_FLAG_SUPERVISOR_MODE support Lu Baolu
2022-04-10 10:24 ` [PATCH RFC v3 06/12] iommu/vt-d: Add SVA domain support Lu Baolu
2022-04-10 10:24 ` [PATCH RFC v3 07/12] arm-smmu-v3/sva: " Lu Baolu
2022-04-10 10:24 ` [PATCH RFC v3 08/12] iommu/sva: Use attach/detach_pasid_dev in SVA interfaces Lu Baolu
2022-04-12 7:19 ` Tian, Kevin
2022-04-12 12:53 ` Lu Baolu [this message]
2022-04-12 23:36 ` Tian, Kevin
2022-04-13 11:57 ` Lu Baolu
2022-04-14 3:44 ` Tian, Kevin
2022-04-10 10:24 ` [PATCH RFC v3 09/12] iommu: Remove SVA related callbacks from iommu ops Lu Baolu
2022-04-10 10:24 ` [PATCH RFC v3 10/12] iommu: Prepare IOMMU domain for IOPF Lu Baolu
2022-04-10 10:24 ` [PATCH RFC v3 11/12] iommu: Per-domain I/O page fault handling Lu Baolu
2022-04-10 10:24 ` [PATCH RFC v3 12/12] iommu: Rename iommu-sva-lib.{c,h} 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=1289f780-143e-004c-41ac-d95b6f18d63c@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=ashok.raj@intel.com \
--cc=eric.auger@redhat.com \
--cc=hch@infradead.org \
--cc=iommu@lists.linux-foundation.org \
--cc=jacob.jun.pan@intel.com \
--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=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