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: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"Pan, Jacob jun" <jacob.jun.pan@intel.com>
Subject: Re: [PATCH RFC 04/11] iommu/vt-d: Add SVA domain support
Date: Mon, 21 Mar 2022 18:37:06 +0800 [thread overview]
Message-ID: <5c4f0b10-1aa6-74cd-333d-46619aa9b27b@linux.intel.com> (raw)
In-Reply-To: <BL1PR11MB527146393985BC3EE2EAF7648C169@BL1PR11MB5271.namprd11.prod.outlook.com>
On 2022/3/21 15:45, Tian, Kevin wrote:
>> From: Lu Baolu <baolu.lu@linux.intel.com>
>> Sent: Sunday, March 20, 2022 2:40 PM
>>
>> Add support for SVA domain allocation and provide an SVA-specific
>> iommu_domain_ops.
>>
>> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
>> ---
>> include/linux/intel-iommu.h | 1 +
>> drivers/iommu/intel/iommu.c | 12 ++++++++++++
>> drivers/iommu/intel/svm.c | 34 ++++++++++++++++++++++++++++++++++
>> 3 files changed, 47 insertions(+)
>>
>> diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
>> index 2f9891cb3d00..c14283137fb5 100644
>> --- a/include/linux/intel-iommu.h
>> +++ b/include/linux/intel-iommu.h
>> @@ -744,6 +744,7 @@ void intel_svm_unbind(struct iommu_sva *handle);
>> u32 intel_svm_get_pasid(struct iommu_sva *handle);
>> int intel_svm_page_response(struct device *dev, struct iommu_fault_event
>> *evt,
>> struct iommu_page_response *msg);
>> +extern const struct iommu_domain_ops intel_svm_domain_ops;
>>
>> struct intel_svm_dev {
>> struct list_head list;
>> diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
>> index c1b91bce1530..d55dca3eacf8 100644
>> --- a/drivers/iommu/intel/iommu.c
>> +++ b/drivers/iommu/intel/iommu.c
>> @@ -4318,6 +4318,18 @@ static struct iommu_domain
>> *intel_iommu_domain_alloc(unsigned type)
>> return domain;
>> case IOMMU_DOMAIN_IDENTITY:
>> return &si_domain->domain;
>> +#ifdef CONFIG_INTEL_IOMMU_SVM
>> + case IOMMU_DOMAIN_SVA:
>> + dmar_domain = alloc_domain(type);
>> + if (!dmar_domain) {
>> + pr_err("Can't allocate sva domain\n");
>> + return NULL;
>> + }
>> + domain = &dmar_domain->domain;
>> + domain->ops = &intel_svm_domain_ops;
>> +
>> + return domain;
>> +#endif /* CONFIG_INTEL_IOMMU_SVM */
>> default:
>> return NULL;
>> }
>> diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
>> index ee5ecde5b318..b9f4dd7057d1 100644
>> --- a/drivers/iommu/intel/svm.c
>> +++ b/drivers/iommu/intel/svm.c
>> @@ -932,3 +932,37 @@ int intel_svm_page_response(struct device *dev,
>> mutex_unlock(&pasid_mutex);
>> return ret;
>> }
>> +
>> +static int intel_svm_attach_dev_pasid(struct iommu_domain *domain,
>> + struct device *dev, ioasid_t pasid)
>> +{
>> + struct device_domain_info *info = dev_iommu_priv_get(dev);
>> + struct mm_struct *mm = domain->sva_cookie;
>> + struct intel_iommu *iommu = info->iommu;
>> + struct iommu_sva *sva;
>> +
>> + mutex_lock(&pasid_mutex);
>> + sva = intel_svm_bind_mm(iommu, dev, mm);
>> + mutex_unlock(&pasid_mutex);
>> +
>
> I'm not sure whether this is the right implementation of this callback.
> In last patch you said it will be used for multiple usages but here it
> is fixed to mm binding.
It is for svm domain ops so it should be mm binding only. For other
usages, they should have different domain ops.
> Also the pasid argument is not used at all
> and instead it is retrieved from mm struct implicitly.
The pasid is not used here because it has already been stored in
mm->pasid. Since it's only for SVM domain, I think it's okay.
>
> Basically SVA requires three steps:
>
> 1) alloc a SVA-type domain;
> 2) construct the domain to wrap mm;
> 3) attach the domain to a PASID;
>
> If we aim .attach_dev_pasid to be generic it may suggest that 1) and 2)
> should be done before .attach_dev_pasid then within this callback it
> just deals with domain/pasid attach in a generic way.
You are right. This code does have room for further cleanup. I would
like to put that in a separated series so that we could focus on the
generic SVA and IOPF refactoring.
>
>> + return IS_ERR_OR_NULL(sva);
>> +}
>> +
>> +static void intel_svm_detach_dev_pasid(struct iommu_domain *domain,
>> + struct device *dev, ioasid_t pasid)
>> +{
>> + mutex_lock(&pasid_mutex);
>> + intel_svm_unbind_mm(dev, pasid);
>> + mutex_unlock(&pasid_mutex);
>> +}
>> +
>> +static void intel_svm_domain_free(struct iommu_domain *domain)
>> +{
>> + kfree(domain);
>> +}
>> +
>> +const struct iommu_domain_ops intel_svm_domain_ops = {
>> + .attach_dev_pasid = intel_svm_attach_dev_pasid,
>> + .detach_dev_pasid = intel_svm_detach_dev_pasid,
>> + .free = intel_svm_domain_free,
>> +};
>> --
>> 2.25.1
>
Best regards,
baolu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2022-03-21 10:37 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-20 6:40 [PATCH RFC 00/11] iommu: SVA and IOPF refactoring Lu Baolu
2022-03-20 6:40 ` [PATCH RFC 01/11] iommu: Add pasid_bits field in struct dev_iommu Lu Baolu
2022-03-21 7:01 ` Tian, Kevin
2022-03-21 10:22 ` Lu Baolu
2022-03-22 0:26 ` Tian, Kevin
2022-03-22 0:48 ` Lu Baolu
2022-03-21 11:22 ` Jean-Philippe Brucker
2022-03-22 0:45 ` Lu Baolu
2022-03-20 6:40 ` [PATCH RFC 02/11] iommu: Add iommu_domain type for SVA Lu Baolu
2022-03-21 7:06 ` Tian, Kevin
2022-03-21 10:23 ` Lu Baolu
2022-03-21 11:47 ` Jason Gunthorpe via iommu
2022-03-22 0:54 ` Lu Baolu
2022-03-20 6:40 ` [PATCH RFC 03/11] iommu: Add attach/detach_dev_pasid domain ops Lu Baolu
2022-03-21 7:13 ` Tian, Kevin
2022-03-21 10:27 ` Lu Baolu
2022-03-21 11:53 ` Jason Gunthorpe via iommu
2022-03-20 6:40 ` [PATCH RFC 04/11] iommu/vt-d: Add SVA domain support Lu Baolu
2022-03-21 7:45 ` Tian, Kevin
2022-03-21 10:37 ` Lu Baolu [this message]
2022-03-21 11:56 ` Jason Gunthorpe via iommu
2022-03-22 4:25 ` Lu Baolu
2022-03-20 6:40 ` [PATCH RFC 05/11] arm-smmu-v3/sva: " Lu Baolu
2022-03-21 11:31 ` Jean-Philippe Brucker
2022-03-21 11:58 ` Jason Gunthorpe via iommu
2022-03-20 6:40 ` [PATCH RFC 06/11] iommu/sva: Use attach/detach_pasid_dev in SVA interfaces Lu Baolu
2022-03-21 8:04 ` Tian, Kevin
2022-03-21 11:01 ` Lu Baolu
2022-03-21 12:03 ` Jason Gunthorpe via iommu
2022-03-21 11:33 ` Jean-Philippe Brucker
2022-03-22 4:29 ` Lu Baolu
2022-03-21 12:05 ` Jason Gunthorpe via iommu
2022-03-22 4:31 ` Lu Baolu
2022-03-20 6:40 ` [PATCH RFC 07/11] iommu: Remove SVA related callbacks from iommu ops Lu Baolu
2022-03-20 6:40 ` [PATCH RFC 08/11] iommu: Handle IO page faults directly Lu Baolu
2022-03-21 11:35 ` Jean-Philippe Brucker
2022-03-22 0:39 ` Tian, Kevin
2022-03-20 6:40 ` [PATCH RFC 09/11] iommu: Add iommu_get_domain_for_dev_pasid() Lu Baolu
2022-03-21 12:40 ` Jason Gunthorpe via iommu
2022-03-22 4:50 ` Lu Baolu
2022-03-20 6:40 ` [PATCH RFC 10/11] iommu: Make IOPF handling framework generic Lu Baolu
2022-03-21 8:09 ` Tian, Kevin
2022-03-21 11:42 ` Jean-Philippe Brucker
2022-03-21 12:43 ` Jason Gunthorpe via iommu
2022-03-22 5:03 ` Lu Baolu
2022-03-22 10:02 ` Jean-Philippe Brucker
2022-03-22 12:15 ` Jason Gunthorpe via iommu
2022-03-22 1:00 ` Tian, Kevin
2022-03-22 10:06 ` Jean-Philippe Brucker
2022-03-22 10:24 ` Tian, Kevin
2022-03-22 10:50 ` Jean-Philippe Brucker
2022-03-21 11:39 ` Jean-Philippe Brucker
2022-03-22 5:28 ` Lu Baolu
2022-03-21 12:50 ` Jason Gunthorpe via iommu
2022-03-22 5:48 ` Lu Baolu
2022-03-20 6:40 ` [PATCH RFC 11/11] 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=5c4f0b10-1aa6-74cd-333d-46619aa9b27b@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=ashok.raj@intel.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 \
/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;
as well as URLs for NNTP newsgroup(s).