* [PATCH v5 1/6] iommu/vt-d: Remove mm->pasid in intel_sva_bind_mm()
2023-09-25 2:38 [PATCH v5 0/6] Share sva domains with all devices bound to a mm Tina Zhang
@ 2023-09-25 2:38 ` Tina Zhang
2023-09-25 2:38 ` [PATCH v5 2/6] iommu: Add mm_get_enqcmd_pasid() helper function Tina Zhang
` (4 subsequent siblings)
5 siblings, 0 replies; 17+ messages in thread
From: Tina Zhang @ 2023-09-25 2:38 UTC (permalink / raw)
To: Jason Gunthorpe, Kevin Tian, Lu Baolu
Cc: Michael Shavit, Vasant Hegde, iommu, linux-kernel, Tina Zhang,
Jason Gunthorpe
The pasid is passed in as a parameter through .set_dev_pasid() callback.
Thus, intel_sva_bind_mm() can directly use it instead of retrieving the
pasid value from mm->pasid.
Suggested-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Tina Zhang <tina.zhang@intel.com>
---
drivers/iommu/intel/svm.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
index 50a481c895b8..3c531af58658 100644
--- a/drivers/iommu/intel/svm.c
+++ b/drivers/iommu/intel/svm.c
@@ -290,21 +290,22 @@ static int pasid_to_svm_sdev(struct device *dev, unsigned int pasid,
}
static int intel_svm_bind_mm(struct intel_iommu *iommu, struct device *dev,
- struct mm_struct *mm)
+ struct iommu_domain *domain, ioasid_t pasid)
{
struct device_domain_info *info = dev_iommu_priv_get(dev);
+ struct mm_struct *mm = domain->mm;
struct intel_svm_dev *sdev;
struct intel_svm *svm;
unsigned long sflags;
int ret = 0;
- svm = pasid_private_find(mm->pasid);
+ svm = pasid_private_find(pasid);
if (!svm) {
svm = kzalloc(sizeof(*svm), GFP_KERNEL);
if (!svm)
return -ENOMEM;
- svm->pasid = mm->pasid;
+ svm->pasid = pasid;
svm->mm = mm;
INIT_LIST_HEAD_RCU(&svm->devs);
@@ -342,7 +343,7 @@ static int intel_svm_bind_mm(struct intel_iommu *iommu, struct device *dev,
/* Setup the pasid table: */
sflags = cpu_feature_enabled(X86_FEATURE_LA57) ? PASID_FLAG_FL5LP : 0;
- ret = intel_pasid_setup_first_level(iommu, dev, mm->pgd, mm->pasid,
+ ret = intel_pasid_setup_first_level(iommu, dev, mm->pgd, pasid,
FLPT_DEFAULT_DID, sflags);
if (ret)
goto free_sdev;
@@ -356,7 +357,7 @@ static int intel_svm_bind_mm(struct intel_iommu *iommu, struct device *dev,
free_svm:
if (list_empty(&svm->devs)) {
mmu_notifier_unregister(&svm->notifier, mm);
- pasid_private_remove(mm->pasid);
+ pasid_private_remove(pasid);
kfree(svm);
}
@@ -796,9 +797,8 @@ static int intel_svm_set_dev_pasid(struct iommu_domain *domain,
{
struct device_domain_info *info = dev_iommu_priv_get(dev);
struct intel_iommu *iommu = info->iommu;
- struct mm_struct *mm = domain->mm;
- return intel_svm_bind_mm(iommu, dev, mm);
+ return intel_svm_bind_mm(iommu, dev, domain, pasid);
}
static void intel_svm_domain_free(struct iommu_domain *domain)
--
2.34.1
^ permalink raw reply related [flat|nested] 17+ messages in thread* [PATCH v5 2/6] iommu: Add mm_get_enqcmd_pasid() helper function
2023-09-25 2:38 [PATCH v5 0/6] Share sva domains with all devices bound to a mm Tina Zhang
2023-09-25 2:38 ` [PATCH v5 1/6] iommu/vt-d: Remove mm->pasid in intel_sva_bind_mm() Tina Zhang
@ 2023-09-25 2:38 ` Tina Zhang
2023-10-05 18:40 ` Jason Gunthorpe
2023-09-25 2:38 ` [PATCH v5 3/6] iommu: Introduce mm_get_pasid() " Tina Zhang
` (3 subsequent siblings)
5 siblings, 1 reply; 17+ messages in thread
From: Tina Zhang @ 2023-09-25 2:38 UTC (permalink / raw)
To: Jason Gunthorpe, Kevin Tian, Lu Baolu
Cc: Michael Shavit, Vasant Hegde, iommu, linux-kernel, Tina Zhang
mm_get_enqcmd_pasid() is for getting enqcmd pasid value.
The motivation is to replace mm->pasid with an iommu private data
structure that is introduced in a later patch.
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Tina Zhang <tina.zhang@intel.com>
---
Change in v2:
- Change mm_get_pasid() to mm_get_enqcmd_pasid()
arch/x86/kernel/traps.c | 2 +-
include/linux/iommu.h | 8 ++++++++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index c876f1d36a81..832f4413d96a 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -591,7 +591,7 @@ static bool try_fixup_enqcmd_gp(void)
if (!mm_valid_pasid(current->mm))
return false;
- pasid = current->mm->pasid;
+ pasid = mm_get_enqcmd_pasid(current->mm);
/*
* Did this thread already have its PASID activated?
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index c50a769d569a..a4eab6697fe1 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -1189,6 +1189,10 @@ static inline bool mm_valid_pasid(struct mm_struct *mm)
{
return mm->pasid != IOMMU_PASID_INVALID;
}
+static inline u32 mm_get_enqcmd_pasid(struct mm_struct *mm)
+{
+ return mm->pasid;
+}
void mm_pasid_drop(struct mm_struct *mm);
struct iommu_sva *iommu_sva_bind_device(struct device *dev,
struct mm_struct *mm);
@@ -1211,6 +1215,10 @@ static inline u32 iommu_sva_get_pasid(struct iommu_sva *handle)
}
static inline void mm_pasid_init(struct mm_struct *mm) {}
static inline bool mm_valid_pasid(struct mm_struct *mm) { return false; }
+static inline u32 mm_get_enqcmd_pasid(struct mm_struct *mm)
+{
+ return IOMMU_PASID_INVALID;
+}
static inline void mm_pasid_drop(struct mm_struct *mm) {}
#endif /* CONFIG_IOMMU_SVA */
--
2.34.1
^ permalink raw reply related [flat|nested] 17+ messages in thread* Re: [PATCH v5 2/6] iommu: Add mm_get_enqcmd_pasid() helper function
2023-09-25 2:38 ` [PATCH v5 2/6] iommu: Add mm_get_enqcmd_pasid() helper function Tina Zhang
@ 2023-10-05 18:40 ` Jason Gunthorpe
0 siblings, 0 replies; 17+ messages in thread
From: Jason Gunthorpe @ 2023-10-05 18:40 UTC (permalink / raw)
To: Tina Zhang
Cc: Kevin Tian, Lu Baolu, Michael Shavit, Vasant Hegde, iommu,
linux-kernel
On Mon, Sep 25, 2023 at 10:38:09AM +0800, Tina Zhang wrote:
> mm_get_enqcmd_pasid() is for getting enqcmd pasid value.
>
> The motivation is to replace mm->pasid with an iommu private data
> structure that is introduced in a later patch.
>
> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
> Signed-off-by: Tina Zhang <tina.zhang@intel.com>
> ---
>
> Change in v2:
> - Change mm_get_pasid() to mm_get_enqcmd_pasid()
>
> arch/x86/kernel/traps.c | 2 +-
> include/linux/iommu.h | 8 ++++++++
> 2 files changed, 9 insertions(+), 1 deletion(-)
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH v5 3/6] iommu: Introduce mm_get_pasid() helper function
2023-09-25 2:38 [PATCH v5 0/6] Share sva domains with all devices bound to a mm Tina Zhang
2023-09-25 2:38 ` [PATCH v5 1/6] iommu/vt-d: Remove mm->pasid in intel_sva_bind_mm() Tina Zhang
2023-09-25 2:38 ` [PATCH v5 2/6] iommu: Add mm_get_enqcmd_pasid() helper function Tina Zhang
@ 2023-09-25 2:38 ` Tina Zhang
2023-10-05 18:44 ` Jason Gunthorpe
2023-09-25 2:38 ` [PATCH v5 4/6] mm: Add structure to keep sva information Tina Zhang
` (2 subsequent siblings)
5 siblings, 1 reply; 17+ messages in thread
From: Tina Zhang @ 2023-09-25 2:38 UTC (permalink / raw)
To: Jason Gunthorpe, Kevin Tian, Lu Baolu
Cc: Michael Shavit, Vasant Hegde, iommu, linux-kernel, Tina Zhang
Use the helper function mm_get_pasid() to get a mm assigned pasid
value. The motivation is to replace mm->pasid with an iommu private
data structure that is introduced in a later patch.
The mm_get_pasid() is intended for generic usage of mm's pasid.
Using mm_get_pasid() for shared virtual addressing (SVA) with enqcmd
usage is discouraged. Instead, one should consider using
mm_get_enqcmd_pasid().
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Tina Zhang <tina.zhang@intel.com>
---
Change in v5:
- Update commit message.
Change in v4:
- Rebase to v6.6-rc1.
Changes in v2:
- Update commit message.
- Let mm_get_enqcmd_pasid() call mm_get_pasid() to get pasid.
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 12 ++++++------
drivers/iommu/iommu-sva.c | 12 ++++++------
include/linux/iommu.h | 10 +++++++++-
3 files changed, 21 insertions(+), 13 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
index 4d83edc2be99..dbb3af323ede 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
@@ -215,7 +215,7 @@ static void arm_smmu_mm_arch_invalidate_secondary_tlbs(struct mmu_notifier *mn,
smmu_domain);
}
- arm_smmu_atc_inv_domain(smmu_domain, mm->pasid, start, size);
+ arm_smmu_atc_inv_domain(smmu_domain, mm_get_pasid(mm), start, size);
}
static void arm_smmu_mm_release(struct mmu_notifier *mn, struct mm_struct *mm)
@@ -233,10 +233,10 @@ static void arm_smmu_mm_release(struct mmu_notifier *mn, struct mm_struct *mm)
* DMA may still be running. Keep the cd valid to avoid C_BAD_CD events,
* but disable translation.
*/
- arm_smmu_write_ctx_desc(smmu_domain, mm->pasid, &quiet_cd);
+ arm_smmu_write_ctx_desc(smmu_domain, mm_get_pasid(mm), &quiet_cd);
arm_smmu_tlb_inv_asid(smmu_domain->smmu, smmu_mn->cd->asid);
- arm_smmu_atc_inv_domain(smmu_domain, mm->pasid, 0, 0);
+ arm_smmu_atc_inv_domain(smmu_domain, mm_get_pasid(mm), 0, 0);
smmu_mn->cleared = true;
mutex_unlock(&sva_lock);
@@ -290,7 +290,7 @@ arm_smmu_mmu_notifier_get(struct arm_smmu_domain *smmu_domain,
goto err_free_cd;
}
- ret = arm_smmu_write_ctx_desc(smmu_domain, mm->pasid, cd);
+ ret = arm_smmu_write_ctx_desc(smmu_domain, mm_get_pasid(mm), cd);
if (ret)
goto err_put_notifier;
@@ -315,7 +315,7 @@ static void arm_smmu_mmu_notifier_put(struct arm_smmu_mmu_notifier *smmu_mn)
return;
list_del(&smmu_mn->list);
- arm_smmu_write_ctx_desc(smmu_domain, mm->pasid, NULL);
+ arm_smmu_write_ctx_desc(smmu_domain, mm_get_pasid(mm), NULL);
/*
* If we went through clear(), we've already invalidated, and no
@@ -323,7 +323,7 @@ static void arm_smmu_mmu_notifier_put(struct arm_smmu_mmu_notifier *smmu_mn)
*/
if (!smmu_mn->cleared) {
arm_smmu_tlb_inv_asid(smmu_domain->smmu, cd->asid);
- arm_smmu_atc_inv_domain(smmu_domain, mm->pasid, 0, 0);
+ arm_smmu_atc_inv_domain(smmu_domain, mm_get_pasid(mm), 0, 0);
}
/* Frees smmu_mn */
diff --git a/drivers/iommu/iommu-sva.c b/drivers/iommu/iommu-sva.c
index b78671a8a914..0f956ecd0c9b 100644
--- a/drivers/iommu/iommu-sva.c
+++ b/drivers/iommu/iommu-sva.c
@@ -23,7 +23,7 @@ static int iommu_sva_alloc_pasid(struct mm_struct *mm, struct device *dev)
mutex_lock(&iommu_sva_lock);
/* Is a PASID already associated with this mm? */
if (mm_valid_pasid(mm)) {
- if (mm->pasid >= dev->iommu->max_pasids)
+ if (mm_get_pasid(mm) >= dev->iommu->max_pasids)
ret = -EOVERFLOW;
goto out;
}
@@ -73,7 +73,7 @@ struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct *mm
mutex_lock(&iommu_sva_lock);
/* Search for an existing domain. */
- domain = iommu_get_domain_for_dev_pasid(dev, mm->pasid,
+ domain = iommu_get_domain_for_dev_pasid(dev, mm_get_pasid(mm),
IOMMU_DOMAIN_SVA);
if (IS_ERR(domain)) {
ret = PTR_ERR(domain);
@@ -92,7 +92,7 @@ struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct *mm
goto out_unlock;
}
- ret = iommu_attach_device_pasid(domain, dev, mm->pasid);
+ ret = iommu_attach_device_pasid(domain, dev, mm_get_pasid(mm));
if (ret)
goto out_free_domain;
domain->users = 1;
@@ -124,7 +124,7 @@ EXPORT_SYMBOL_GPL(iommu_sva_bind_device);
void iommu_sva_unbind_device(struct iommu_sva *handle)
{
struct iommu_domain *domain = handle->domain;
- ioasid_t pasid = domain->mm->pasid;
+ ioasid_t pasid = mm_get_pasid(domain->mm);
struct device *dev = handle->dev;
mutex_lock(&iommu_sva_lock);
@@ -141,7 +141,7 @@ u32 iommu_sva_get_pasid(struct iommu_sva *handle)
{
struct iommu_domain *domain = handle->domain;
- return domain->mm->pasid;
+ return mm_get_pasid(domain->mm);
}
EXPORT_SYMBOL_GPL(iommu_sva_get_pasid);
@@ -208,5 +208,5 @@ void mm_pasid_drop(struct mm_struct *mm)
if (likely(!mm_valid_pasid(mm)))
return;
- iommu_free_global_pasid(mm->pasid);
+ iommu_free_global_pasid(mm_get_pasid(mm));
}
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index a4eab6697fe1..db2510da28c1 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -1189,10 +1189,14 @@ static inline bool mm_valid_pasid(struct mm_struct *mm)
{
return mm->pasid != IOMMU_PASID_INVALID;
}
-static inline u32 mm_get_enqcmd_pasid(struct mm_struct *mm)
+static inline u32 mm_get_pasid(struct mm_struct *mm)
{
return mm->pasid;
}
+static inline u32 mm_get_enqcmd_pasid(struct mm_struct *mm)
+{
+ return mm_get_pasid(mm);
+}
void mm_pasid_drop(struct mm_struct *mm);
struct iommu_sva *iommu_sva_bind_device(struct device *dev,
struct mm_struct *mm);
@@ -1215,6 +1219,10 @@ static inline u32 iommu_sva_get_pasid(struct iommu_sva *handle)
}
static inline void mm_pasid_init(struct mm_struct *mm) {}
static inline bool mm_valid_pasid(struct mm_struct *mm) { return false; }
+static inline u32 mm_get_pasid(struct mm_struct *mm)
+{
+ return IOMMU_PASID_INVALID;
+}
static inline u32 mm_get_enqcmd_pasid(struct mm_struct *mm)
{
return IOMMU_PASID_INVALID;
--
2.34.1
^ permalink raw reply related [flat|nested] 17+ messages in thread* Re: [PATCH v5 3/6] iommu: Introduce mm_get_pasid() helper function
2023-09-25 2:38 ` [PATCH v5 3/6] iommu: Introduce mm_get_pasid() " Tina Zhang
@ 2023-10-05 18:44 ` Jason Gunthorpe
0 siblings, 0 replies; 17+ messages in thread
From: Jason Gunthorpe @ 2023-10-05 18:44 UTC (permalink / raw)
To: Tina Zhang
Cc: Kevin Tian, Lu Baolu, Michael Shavit, Vasant Hegde, iommu,
linux-kernel
On Mon, Sep 25, 2023 at 10:38:10AM +0800, Tina Zhang wrote:
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index a4eab6697fe1..db2510da28c1 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -1189,10 +1189,14 @@ static inline bool mm_valid_pasid(struct mm_struct *mm)
> {
> return mm->pasid != IOMMU_PASID_INVALID;
> }
> -static inline u32 mm_get_enqcmd_pasid(struct mm_struct *mm)
> +static inline u32 mm_get_pasid(struct mm_struct *mm)
This should not be in a global header
Put the mm_get_pasid() in iommu-sva.c as a helper
Have SMMUv3 call mm_get_enqcmd_pasid() for now, it will be fixed
There is no "mm_pasid" that should leak outside of iommu-sva.c except
specifically to support enqcmd.
Jason
^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH v5 4/6] mm: Add structure to keep sva information
2023-09-25 2:38 [PATCH v5 0/6] Share sva domains with all devices bound to a mm Tina Zhang
` (2 preceding siblings ...)
2023-09-25 2:38 ` [PATCH v5 3/6] iommu: Introduce mm_get_pasid() " Tina Zhang
@ 2023-09-25 2:38 ` Tina Zhang
2023-10-05 18:49 ` Jason Gunthorpe
2023-09-25 2:38 ` [PATCH v5 5/6] iommu: Support mm PASID 1:n with sva domains Tina Zhang
2023-09-25 2:38 ` [PATCH v5 6/6] mm: Deprecate pasid field Tina Zhang
5 siblings, 1 reply; 17+ messages in thread
From: Tina Zhang @ 2023-09-25 2:38 UTC (permalink / raw)
To: Jason Gunthorpe, Kevin Tian, Lu Baolu
Cc: Michael Shavit, Vasant Hegde, iommu, linux-kernel, Tina Zhang
Introduce iommu_mm_data structure to keep sva information (pasid and the
related sva domains). Add iommu_mm pointer, pointing to an instance of
iommu_mm_data structure, to mm.
Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Tina Zhang <tina.zhang@intel.com>
---
include/linux/iommu.h | 5 +++++
include/linux/mm_types.h | 2 ++
2 files changed, 7 insertions(+)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index db2510da28c1..b9c9f14a95cc 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -670,6 +670,11 @@ struct iommu_sva {
struct iommu_domain *domain;
};
+struct iommu_mm_data {
+ u32 pasid;
+ struct list_head sva_domains;
+};
+
int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode,
const struct iommu_ops *ops);
void iommu_fwspec_free(struct device *dev);
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 36c5b43999e6..9f4efed85f74 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -670,6 +670,7 @@ struct mm_cid {
#endif
struct kioctx_table;
+struct iommu_mm_data;
struct mm_struct {
struct {
/*
@@ -883,6 +884,7 @@ struct mm_struct {
#ifdef CONFIG_IOMMU_SVA
u32 pasid;
+ struct iommu_mm_data *iommu_mm;
#endif
#ifdef CONFIG_KSM
/*
--
2.34.1
^ permalink raw reply related [flat|nested] 17+ messages in thread* Re: [PATCH v5 4/6] mm: Add structure to keep sva information
2023-09-25 2:38 ` [PATCH v5 4/6] mm: Add structure to keep sva information Tina Zhang
@ 2023-10-05 18:49 ` Jason Gunthorpe
0 siblings, 0 replies; 17+ messages in thread
From: Jason Gunthorpe @ 2023-10-05 18:49 UTC (permalink / raw)
To: Tina Zhang
Cc: Kevin Tian, Lu Baolu, Michael Shavit, Vasant Hegde, iommu,
linux-kernel
On Mon, Sep 25, 2023 at 10:38:11AM +0800, Tina Zhang wrote:
> Introduce iommu_mm_data structure to keep sva information (pasid and the
> related sva domains). Add iommu_mm pointer, pointing to an instance of
> iommu_mm_data structure, to mm.
>
> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
> Signed-off-by: Tina Zhang <tina.zhang@intel.com>
> ---
> include/linux/iommu.h | 5 +++++
> include/linux/mm_types.h | 2 ++
> 2 files changed, 7 insertions(+)
This is fine, but you could probably squash patches 4/5/6
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH v5 5/6] iommu: Support mm PASID 1:n with sva domains
2023-09-25 2:38 [PATCH v5 0/6] Share sva domains with all devices bound to a mm Tina Zhang
` (3 preceding siblings ...)
2023-09-25 2:38 ` [PATCH v5 4/6] mm: Add structure to keep sva information Tina Zhang
@ 2023-09-25 2:38 ` Tina Zhang
2023-10-05 18:49 ` Jason Gunthorpe
` (2 more replies)
2023-09-25 2:38 ` [PATCH v5 6/6] mm: Deprecate pasid field Tina Zhang
5 siblings, 3 replies; 17+ messages in thread
From: Tina Zhang @ 2023-09-25 2:38 UTC (permalink / raw)
To: Jason Gunthorpe, Kevin Tian, Lu Baolu
Cc: Michael Shavit, Vasant Hegde, iommu, linux-kernel, Tina Zhang
Each mm bound to devices gets a PASID and corresponding sva domains
allocated in iommu_sva_bind_device(), which are referenced by iommu_mm
field of the mm. The PASID is released in __mmdrop(), while a sva domain
is released when no one is using it (the reference count is decremented
in iommu_sva_unbind_device()). However, although sva domains and their
PASID are separate objects such that their own life cycles could be
handled independently, an enqcmd use case may require releasing the
PASID in releasing the mm (i.e., once a PASID is allocated for a mm, it
will be permanently used by the mm and won't be released until the end
of mm) and only allows to drop the PASID after the sva domains are
released. To this end, mmgrab() is called in iommu_sva_domain_alloc() to
increment the mm reference count and mmdrop() is invoked in
iommu_domain_free() to decrement the mm reference count.
Since the required info of PASID and sva domains is kept in struct
iommu_mm_data of a mm, use mm->iommu_mm field instead of the old pasid
field in mm struct. The sva domain list is protected by iommu_sva_lock.
Besides, this patch removes mm_pasid_init(), as with the introduced
iommu_mm structure, initializing mm pasid in mm_init() is unnecessary.
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
Signed-off-by: Tina Zhang <tina.zhang@intel.com>
---
Change in v5:
- Use smp_store_release() & READ_ONCE() in storing and loading mm's
pasid value.
Change in v4:
- Rebase to v6.6-rc1.
drivers/iommu/iommu-sva.c | 40 +++++++++++++++++++++++++++------------
include/linux/iommu.h | 18 +++++++++++-------
kernel/fork.c | 1 -
3 files changed, 39 insertions(+), 20 deletions(-)
diff --git a/drivers/iommu/iommu-sva.c b/drivers/iommu/iommu-sva.c
index 0f956ecd0c9b..b2c1db1ae385 100644
--- a/drivers/iommu/iommu-sva.c
+++ b/drivers/iommu/iommu-sva.c
@@ -15,6 +15,7 @@ static DEFINE_MUTEX(iommu_sva_lock);
static int iommu_sva_alloc_pasid(struct mm_struct *mm, struct device *dev)
{
ioasid_t pasid;
+ struct iommu_mm_data *iommu_mm;
int ret = 0;
if (!arch_pgtable_dma_compat(mm))
@@ -28,12 +29,27 @@ static int iommu_sva_alloc_pasid(struct mm_struct *mm, struct device *dev)
goto out;
}
+ iommu_mm = kzalloc(sizeof(struct iommu_mm_data), GFP_KERNEL);
+ if (!iommu_mm) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
pasid = iommu_alloc_global_pasid(dev);
if (pasid == IOMMU_PASID_INVALID) {
+ kfree(iommu_mm);
ret = -ENOSPC;
goto out;
}
- mm->pasid = pasid;
+ iommu_mm->pasid = pasid;
+ INIT_LIST_HEAD(&iommu_mm->sva_domains);
+ /*
+ * Make sure the write to mm->iommu_mm is not reordered in front of
+ * initialization to iommu_mm fields. If it does, readers may see a
+ * valid iommu_mm with uninitialized values.
+ */
+ smp_store_release(&mm->iommu_mm, iommu_mm);
+
ret = 0;
out:
mutex_unlock(&iommu_sva_lock);
@@ -73,16 +89,12 @@ struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct *mm
mutex_lock(&iommu_sva_lock);
/* Search for an existing domain. */
- domain = iommu_get_domain_for_dev_pasid(dev, mm_get_pasid(mm),
- IOMMU_DOMAIN_SVA);
- if (IS_ERR(domain)) {
- ret = PTR_ERR(domain);
- goto out_unlock;
- }
-
- if (domain) {
- domain->users++;
- goto out;
+ list_for_each_entry(domain, &mm->iommu_mm->sva_domains, next) {
+ ret = iommu_attach_device_pasid(domain, dev, mm_get_pasid(mm));
+ if (!ret) {
+ domain->users++;
+ goto out;
+ }
}
/* Allocate a new domain and set it on device pasid. */
@@ -96,6 +108,8 @@ struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct *mm
if (ret)
goto out_free_domain;
domain->users = 1;
+ list_add(&domain->next, &mm->iommu_mm->sva_domains);
+
out:
mutex_unlock(&iommu_sva_lock);
handle->dev = dev;
@@ -128,8 +142,9 @@ void iommu_sva_unbind_device(struct iommu_sva *handle)
struct device *dev = handle->dev;
mutex_lock(&iommu_sva_lock);
+ iommu_detach_device_pasid(domain, dev, pasid);
if (--domain->users == 0) {
- iommu_detach_device_pasid(domain, dev, pasid);
+ list_del(&domain->next);
iommu_domain_free(domain);
}
mutex_unlock(&iommu_sva_lock);
@@ -209,4 +224,5 @@ void mm_pasid_drop(struct mm_struct *mm)
return;
iommu_free_global_pasid(mm_get_pasid(mm));
+ kfree(mm->iommu_mm);
}
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index b9c9f14a95cc..cf8febaa4d80 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -109,6 +109,11 @@ struct iommu_domain {
struct { /* IOMMU_DOMAIN_SVA */
struct mm_struct *mm;
int users;
+ /*
+ * Next iommu_domain in mm->iommu_mm->sva-domains list
+ * protected by iommu_sva_lock.
+ */
+ struct list_head next;
};
};
};
@@ -1186,17 +1191,17 @@ static inline bool tegra_dev_iommu_get_stream_id(struct device *dev, u32 *stream
}
#ifdef CONFIG_IOMMU_SVA
-static inline void mm_pasid_init(struct mm_struct *mm)
-{
- mm->pasid = IOMMU_PASID_INVALID;
-}
static inline bool mm_valid_pasid(struct mm_struct *mm)
{
- return mm->pasid != IOMMU_PASID_INVALID;
+ return READ_ONCE(mm->iommu_mm);
}
static inline u32 mm_get_pasid(struct mm_struct *mm)
{
- return mm->pasid;
+ struct iommu_mm_data *iommu_mm = READ_ONCE(mm->iommu_mm);
+
+ if (!iommu_mm)
+ return IOMMU_PASID_INVALID;
+ return iommu_mm->pasid;
}
static inline u32 mm_get_enqcmd_pasid(struct mm_struct *mm)
{
@@ -1222,7 +1227,6 @@ static inline u32 iommu_sva_get_pasid(struct iommu_sva *handle)
{
return IOMMU_PASID_INVALID;
}
-static inline void mm_pasid_init(struct mm_struct *mm) {}
static inline bool mm_valid_pasid(struct mm_struct *mm) { return false; }
static inline u32 mm_get_pasid(struct mm_struct *mm)
{
diff --git a/kernel/fork.c b/kernel/fork.c
index 3b6d20dfb9a8..985403a7a747 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1277,7 +1277,6 @@ static struct mm_struct *mm_init(struct mm_struct *mm, struct task_struct *p,
mm_init_cpumask(mm);
mm_init_aio(mm);
mm_init_owner(mm, p);
- mm_pasid_init(mm);
RCU_INIT_POINTER(mm->exe_file, NULL);
mmu_notifier_subscriptions_init(mm);
init_tlb_flush_pending(mm);
--
2.34.1
^ permalink raw reply related [flat|nested] 17+ messages in thread* Re: [PATCH v5 5/6] iommu: Support mm PASID 1:n with sva domains
2023-09-25 2:38 ` [PATCH v5 5/6] iommu: Support mm PASID 1:n with sva domains Tina Zhang
@ 2023-10-05 18:49 ` Jason Gunthorpe
2023-10-06 8:07 ` Nicolin Chen
2023-10-06 18:06 ` Jason Gunthorpe
2 siblings, 0 replies; 17+ messages in thread
From: Jason Gunthorpe @ 2023-10-05 18:49 UTC (permalink / raw)
To: Tina Zhang
Cc: Kevin Tian, Lu Baolu, Michael Shavit, Vasant Hegde, iommu,
linux-kernel
On Mon, Sep 25, 2023 at 10:38:12AM +0800, Tina Zhang wrote:
> Each mm bound to devices gets a PASID and corresponding sva domains
> allocated in iommu_sva_bind_device(), which are referenced by iommu_mm
> field of the mm. The PASID is released in __mmdrop(), while a sva domain
> is released when no one is using it (the reference count is decremented
> in iommu_sva_unbind_device()). However, although sva domains and their
> PASID are separate objects such that their own life cycles could be
> handled independently, an enqcmd use case may require releasing the
> PASID in releasing the mm (i.e., once a PASID is allocated for a mm, it
> will be permanently used by the mm and won't be released until the end
> of mm) and only allows to drop the PASID after the sva domains are
> released. To this end, mmgrab() is called in iommu_sva_domain_alloc() to
> increment the mm reference count and mmdrop() is invoked in
> iommu_domain_free() to decrement the mm reference count.
>
> Since the required info of PASID and sva domains is kept in struct
> iommu_mm_data of a mm, use mm->iommu_mm field instead of the old pasid
> field in mm struct. The sva domain list is protected by iommu_sva_lock.
>
> Besides, this patch removes mm_pasid_init(), as with the introduced
> iommu_mm structure, initializing mm pasid in mm_init() is unnecessary.
>
> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
> Signed-off-by: Tina Zhang <tina.zhang@intel.com>
> ---
>
> Change in v5:
> - Use smp_store_release() & READ_ONCE() in storing and loading mm's
> pasid value.
>
> Change in v4:
> - Rebase to v6.6-rc1.
>
> drivers/iommu/iommu-sva.c | 40 +++++++++++++++++++++++++++------------
> include/linux/iommu.h | 18 +++++++++++-------
> kernel/fork.c | 1 -
> 3 files changed, 39 insertions(+), 20 deletions(-)
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v5 5/6] iommu: Support mm PASID 1:n with sva domains
2023-09-25 2:38 ` [PATCH v5 5/6] iommu: Support mm PASID 1:n with sva domains Tina Zhang
2023-10-05 18:49 ` Jason Gunthorpe
@ 2023-10-06 8:07 ` Nicolin Chen
2023-10-10 11:21 ` Tina Zhang
2023-10-06 18:06 ` Jason Gunthorpe
2 siblings, 1 reply; 17+ messages in thread
From: Nicolin Chen @ 2023-10-06 8:07 UTC (permalink / raw)
To: Tina Zhang
Cc: Jason Gunthorpe, Kevin Tian, Lu Baolu, Michael Shavit,
Vasant Hegde, iommu@lists.linux.dev, linux-kernel@vger.kernel.org
Hi Tina,
On Sun, Sep 24, 2023 at 07:38:12PM -0700, Tina Zhang wrote:
> Each mm bound to devices gets a PASID and corresponding sva domains
> allocated in iommu_sva_bind_device(), which are referenced by iommu_mm
> field of the mm. The PASID is released in __mmdrop(), while a sva domain
> is released when no one is using it (the reference count is decremented
> in iommu_sva_unbind_device()). However, although sva domains and their
> PASID are separate objects such that their own life cycles could be
> handled independently, an enqcmd use case may require releasing the
> PASID in releasing the mm (i.e., once a PASID is allocated for a mm, it
> will be permanently used by the mm and won't be released until the end
> of mm) and only allows to drop the PASID after the sva domains are
> released. To this end, mmgrab() is called in iommu_sva_domain_alloc() to
> increment the mm reference count and mmdrop() is invoked in
> iommu_domain_free() to decrement the mm reference count.
>
> Since the required info of PASID and sva domains is kept in struct
> iommu_mm_data of a mm, use mm->iommu_mm field instead of the old pasid
> field in mm struct. The sva domain list is protected by iommu_sva_lock.
>
> Besides, this patch removes mm_pasid_init(), as with the introduced
> iommu_mm structure, initializing mm pasid in mm_init() is unnecessary.
>
> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
> Signed-off-by: Tina Zhang <tina.zhang@intel.com>
> @@ -128,8 +142,9 @@ void iommu_sva_unbind_device(struct iommu_sva *handle)
> struct device *dev = handle->dev;
>
> mutex_lock(&iommu_sva_lock);
> + iommu_detach_device_pasid(domain, dev, pasid);
> if (--domain->users == 0) {
> - iommu_detach_device_pasid(domain, dev, pasid);
> + list_del(&domain->next);
> iommu_domain_free(domain);
> }
> mutex_unlock(&iommu_sva_lock);
> @@ -209,4 +224,5 @@ void mm_pasid_drop(struct mm_struct *mm)
> return;
>
> iommu_free_global_pasid(mm_get_pasid(mm));
> + kfree(mm->iommu_mm);
I ran some SVA tests by applying this series on top of my local
SMMUv3 tree, though it is not exactly a vanilla mainline tree.
And I see a WARN_ON introduced by this patch (did git-bisect):
[ 364.237319] ------------[ cut here ]------------
[ 364.237328] ida_free called for id=12 which is not allocated.
[ 364.237346] WARNING: CPU: 2 PID: 11003 at lib/idr.c:525 ida_free+0x10c/0x1d0
....
[ 364.237415] pc : ida_free+0x10c/0x1d0
[ 364.237416] lr : ida_free+0x10c/0x1d0
....
[ 364.237439] Call trace:
[ 364.237440] ida_free+0x10c/0x1d0
[ 364.237442] iommu_free_global_pasid+0x30/0x50
[ 364.237449] mm_pasid_drop+0x44/0x70
[ 364.237452] __mmdrop+0xf4/0x210
[ 364.237457] finish_task_switch.isra.0+0x238/0x2e8
[ 364.237460] schedule_tail+0x1c/0x1b8
[ 364.237462] ret_from_fork+0x4/0x20
[ 364.237466] irq event stamp: 0
[ 364.237467] hardirqs last enabled at (0): [<0000000000000000>] 0x0
[ 364.237470] hardirqs last disabled at (0): [<ffffc0c16022e558>] copy_process+0x770/0x1c78
[ 364.237473] softirqs last enabled at (0): [<ffffc0c16022e558>] copy_process+0x770/0x1c78
[ 364.237475] softirqs last disabled at (0): [<0000000000000000>] 0x0
[ 364.237476] ---[ end trace 0000000000000000 ]---
I haven't traced it closely to see what's wrong, due to some other
tasks. Yet, if you have some idea about this or something that you
want me to try, let me know.
Thanks
Nicolin
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH v5 5/6] iommu: Support mm PASID 1:n with sva domains
2023-10-06 8:07 ` Nicolin Chen
@ 2023-10-10 11:21 ` Tina Zhang
2023-10-11 7:07 ` Zhang, Tina
0 siblings, 1 reply; 17+ messages in thread
From: Tina Zhang @ 2023-10-10 11:21 UTC (permalink / raw)
To: Nicolin Chen
Cc: Jason Gunthorpe, Kevin Tian, Lu Baolu, Michael Shavit,
Vasant Hegde, iommu@lists.linux.dev, linux-kernel@vger.kernel.org
Hi Nicolin,
On 10/6/23 16:07, Nicolin Chen wrote:
> Hi Tina,
>
> On Sun, Sep 24, 2023 at 07:38:12PM -0700, Tina Zhang wrote:
>
>> Each mm bound to devices gets a PASID and corresponding sva domains
>> allocated in iommu_sva_bind_device(), which are referenced by iommu_mm
>> field of the mm. The PASID is released in __mmdrop(), while a sva domain
>> is released when no one is using it (the reference count is decremented
>> in iommu_sva_unbind_device()). However, although sva domains and their
>> PASID are separate objects such that their own life cycles could be
>> handled independently, an enqcmd use case may require releasing the
>> PASID in releasing the mm (i.e., once a PASID is allocated for a mm, it
>> will be permanently used by the mm and won't be released until the end
>> of mm) and only allows to drop the PASID after the sva domains are
>> released. To this end, mmgrab() is called in iommu_sva_domain_alloc() to
>> increment the mm reference count and mmdrop() is invoked in
>> iommu_domain_free() to decrement the mm reference count.
>>
>> Since the required info of PASID and sva domains is kept in struct
>> iommu_mm_data of a mm, use mm->iommu_mm field instead of the old pasid
>> field in mm struct. The sva domain list is protected by iommu_sva_lock.
>>
>> Besides, this patch removes mm_pasid_init(), as with the introduced
>> iommu_mm structure, initializing mm pasid in mm_init() is unnecessary.
>>
>> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
>> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
>> Signed-off-by: Tina Zhang <tina.zhang@intel.com>
>
>> @@ -128,8 +142,9 @@ void iommu_sva_unbind_device(struct iommu_sva *handle)
>> struct device *dev = handle->dev;
>>
>> mutex_lock(&iommu_sva_lock);
>> + iommu_detach_device_pasid(domain, dev, pasid);
>> if (--domain->users == 0) {
>> - iommu_detach_device_pasid(domain, dev, pasid);
>> + list_del(&domain->next);
>> iommu_domain_free(domain);
>> }
>> mutex_unlock(&iommu_sva_lock);
>> @@ -209,4 +224,5 @@ void mm_pasid_drop(struct mm_struct *mm)
>> return;
>>
>> iommu_free_global_pasid(mm_get_pasid(mm));
>> + kfree(mm->iommu_mm);
>
> I ran some SVA tests by applying this series on top of my local
> SMMUv3 tree, though it is not exactly a vanilla mainline tree.
> And I see a WARN_ON introduced by this patch (did git-bisect):
>
> [ 364.237319] ------------[ cut here ]------------
> [ 364.237328] ida_free called for id=12 which is not allocated.
> [ 364.237346] WARNING: CPU: 2 PID: 11003 at lib/idr.c:525 ida_free+0x10c/0x1d0
> ....
> [ 364.237415] pc : ida_free+0x10c/0x1d0
> [ 364.237416] lr : ida_free+0x10c/0x1d0
> ....
> [ 364.237439] Call trace:
> [ 364.237440] ida_free+0x10c/0x1d0
> [ 364.237442] iommu_free_global_pasid+0x30/0x50
> [ 364.237449] mm_pasid_drop+0x44/0x70
> [ 364.237452] __mmdrop+0xf4/0x210
> [ 364.237457] finish_task_switch.isra.0+0x238/0x2e8
> [ 364.237460] schedule_tail+0x1c/0x1b8
> [ 364.237462] ret_from_fork+0x4/0x20
> [ 364.237466] irq event stamp: 0
> [ 364.237467] hardirqs last enabled at (0): [<0000000000000000>] 0x0
> [ 364.237470] hardirqs last disabled at (0): [<ffffc0c16022e558>] copy_process+0x770/0x1c78
> [ 364.237473] softirqs last enabled at (0): [<ffffc0c16022e558>] copy_process+0x770/0x1c78
> [ 364.237475] softirqs last disabled at (0): [<0000000000000000>] 0x0
> [ 364.237476] ---[ end trace 0000000000000000 ]---
>
> I haven't traced it closely to see what's wrong, due to some other
> tasks. Yet, if you have some idea about this or something that you
> want me to try, let me know.
Thanks for reporting this issue. I did some sva tests, but didn't run
into this issue. I'm going to try more cases and let you know if I can
find anything interesting.
Regards,
-Tina
>
> Thanks
> Nicolin
^ permalink raw reply [flat|nested] 17+ messages in thread* RE: [PATCH v5 5/6] iommu: Support mm PASID 1:n with sva domains
2023-10-10 11:21 ` Tina Zhang
@ 2023-10-11 7:07 ` Zhang, Tina
0 siblings, 0 replies; 17+ messages in thread
From: Zhang, Tina @ 2023-10-11 7:07 UTC (permalink / raw)
To: Nicolin Chen
Cc: Jason Gunthorpe, Tian, Kevin, Lu Baolu, Michael Shavit,
Vasant Hegde, iommu@lists.linux.dev, linux-kernel@vger.kernel.org
Hi Nicolin,
The v6 version has submitted: https://lore.kernel.org/linux-iommu/20231011065132.102676-1-tina.zhang@intel.com/
In v6 version, we make the iommu_sva_lock holding as a precondition for iommu_alloc_mm_data(). Although I think the issue you met probably wasn't caused by the iommu_sva_lock holding logic in iommu_sva_bind_device() of v5 patch-set. I guess it's worth a try.
Regards,
-Tina
> -----Original Message-----
> From: Zhang, Tina
> Sent: Tuesday, October 10, 2023 7:22 PM
> To: Nicolin Chen <nicolinc@nvidia.com>
> Cc: Jason Gunthorpe <jgg@ziepe.ca>; Tian, Kevin <kevin.tian@intel.com>; Lu
> Baolu <baolu.lu@linux.intel.com>; Michael Shavit <mshavit@google.com>;
> Vasant Hegde <vasant.hegde@amd.com>; iommu@lists.linux.dev; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH v5 5/6] iommu: Support mm PASID 1:n with sva domains
>
> Hi Nicolin,
>
> On 10/6/23 16:07, Nicolin Chen wrote:
> > Hi Tina,
> >
> > On Sun, Sep 24, 2023 at 07:38:12PM -0700, Tina Zhang wrote:
> >
> >> Each mm bound to devices gets a PASID and corresponding sva domains
> >> allocated in iommu_sva_bind_device(), which are referenced by
> >> iommu_mm field of the mm. The PASID is released in __mmdrop(), while
> >> a sva domain is released when no one is using it (the reference count
> >> is decremented in iommu_sva_unbind_device()). However, although sva
> >> domains and their PASID are separate objects such that their own life
> >> cycles could be handled independently, an enqcmd use case may require
> >> releasing the PASID in releasing the mm (i.e., once a PASID is
> >> allocated for a mm, it will be permanently used by the mm and won't
> >> be released until the end of mm) and only allows to drop the PASID
> >> after the sva domains are released. To this end, mmgrab() is called
> >> in iommu_sva_domain_alloc() to increment the mm reference count and
> >> mmdrop() is invoked in
> >> iommu_domain_free() to decrement the mm reference count.
> >>
> >> Since the required info of PASID and sva domains is kept in struct
> >> iommu_mm_data of a mm, use mm->iommu_mm field instead of the old
> >> pasid field in mm struct. The sva domain list is protected by
> iommu_sva_lock.
> >>
> >> Besides, this patch removes mm_pasid_init(), as with the introduced
> >> iommu_mm structure, initializing mm pasid in mm_init() is unnecessary.
> >>
> >> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
> >> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
> >> Signed-off-by: Tina Zhang <tina.zhang@intel.com>
> >
> >> @@ -128,8 +142,9 @@ void iommu_sva_unbind_device(struct iommu_sva
> *handle)
> >> struct device *dev = handle->dev;
> >>
> >> mutex_lock(&iommu_sva_lock);
> >> + iommu_detach_device_pasid(domain, dev, pasid);
> >> if (--domain->users == 0) {
> >> - iommu_detach_device_pasid(domain, dev, pasid);
> >> + list_del(&domain->next);
> >> iommu_domain_free(domain);
> >> }
> >> mutex_unlock(&iommu_sva_lock); @@ -209,4 +224,5 @@ void
> >> mm_pasid_drop(struct mm_struct *mm)
> >> return;
> >>
> >> iommu_free_global_pasid(mm_get_pasid(mm));
> >> + kfree(mm->iommu_mm);
> >
> > I ran some SVA tests by applying this series on top of my local
> > SMMUv3 tree, though it is not exactly a vanilla mainline tree.
> > And I see a WARN_ON introduced by this patch (did git-bisect):
> >
> > [ 364.237319] ------------[ cut here ]------------ [ 364.237328]
> > ida_free called for id=12 which is not allocated.
> > [ 364.237346] WARNING: CPU: 2 PID: 11003 at lib/idr.c:525
> > ida_free+0x10c/0x1d0 ....
> > [ 364.237415] pc : ida_free+0x10c/0x1d0 [ 364.237416] lr :
> > ida_free+0x10c/0x1d0 ....
> > [ 364.237439] Call trace:
> > [ 364.237440] ida_free+0x10c/0x1d0
> > [ 364.237442] iommu_free_global_pasid+0x30/0x50 [ 364.237449]
> > mm_pasid_drop+0x44/0x70 [ 364.237452] __mmdrop+0xf4/0x210 [
> > 364.237457] finish_task_switch.isra.0+0x238/0x2e8
> > [ 364.237460] schedule_tail+0x1c/0x1b8 [ 364.237462]
> > ret_from_fork+0x4/0x20 [ 364.237466] irq event stamp: 0 [
> > 364.237467] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [
> > 364.237470] hardirqs last disabled at (0): [<ffffc0c16022e558>]
> > copy_process+0x770/0x1c78 [ 364.237473] softirqs last enabled at
> > (0): [<ffffc0c16022e558>] copy_process+0x770/0x1c78 [ 364.237475]
> > softirqs last disabled at (0): [<0000000000000000>] 0x0 [ 364.237476]
> > ---[ end trace 0000000000000000 ]---
> >
> > I haven't traced it closely to see what's wrong, due to some other
> > tasks. Yet, if you have some idea about this or something that you
> > want me to try, let me know.
> Thanks for reporting this issue. I did some sva tests, but didn't run into this
> issue. I'm going to try more cases and let you know if I can find anything
> interesting.
>
>
> Regards,
> -Tina
>
> >
> > Thanks
> > Nicolin
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v5 5/6] iommu: Support mm PASID 1:n with sva domains
2023-09-25 2:38 ` [PATCH v5 5/6] iommu: Support mm PASID 1:n with sva domains Tina Zhang
2023-10-05 18:49 ` Jason Gunthorpe
2023-10-06 8:07 ` Nicolin Chen
@ 2023-10-06 18:06 ` Jason Gunthorpe
2023-10-10 13:38 ` Zhang, Tina
2 siblings, 1 reply; 17+ messages in thread
From: Jason Gunthorpe @ 2023-10-06 18:06 UTC (permalink / raw)
To: Tina Zhang
Cc: Kevin Tian, Lu Baolu, Michael Shavit, Vasant Hegde, iommu,
linux-kernel
On Mon, Sep 25, 2023 at 10:38:12AM +0800, Tina Zhang wrote:
> Each mm bound to devices gets a PASID and corresponding sva domains
> allocated in iommu_sva_bind_device(), which are referenced by iommu_mm
> field of the mm. The PASID is released in __mmdrop(), while a sva domain
> is released when no one is using it (the reference count is decremented
> in iommu_sva_unbind_device()). However, although sva domains and their
> PASID are separate objects such that their own life cycles could be
> handled independently, an enqcmd use case may require releasing the
> PASID in releasing the mm (i.e., once a PASID is allocated for a mm, it
> will be permanently used by the mm and won't be released until the end
> of mm) and only allows to drop the PASID after the sva domains are
> released. To this end, mmgrab() is called in iommu_sva_domain_alloc() to
> increment the mm reference count and mmdrop() is invoked in
> iommu_domain_free() to decrement the mm reference count.
>
> Since the required info of PASID and sva domains is kept in struct
> iommu_mm_data of a mm, use mm->iommu_mm field instead of the old pasid
> field in mm struct. The sva domain list is protected by iommu_sva_lock.
>
> Besides, this patch removes mm_pasid_init(), as with the introduced
> iommu_mm structure, initializing mm pasid in mm_init() is unnecessary.
>
> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
> Signed-off-by: Tina Zhang <tina.zhang@intel.com>
> ---
>
> Change in v5:
> - Use smp_store_release() & READ_ONCE() in storing and loading mm's
> pasid value.
>
> Change in v4:
> - Rebase to v6.6-rc1.
>
> drivers/iommu/iommu-sva.c | 40 +++++++++++++++++++++++++++------------
> include/linux/iommu.h | 18 +++++++++++-------
> kernel/fork.c | 1 -
> 3 files changed, 39 insertions(+), 20 deletions(-)
I was wondering what Nicolin's issue was, didn't see anything.
But I think you should incorporate this into the patch.
And there is a straightforward way to move the global lock into the
iommu_mm_data that we can explore later.
diff --git a/drivers/iommu/iommu-sva.c b/drivers/iommu/iommu-sva.c
index b2c1db1ae385b0..e712554ea3656f 100644
--- a/drivers/iommu/iommu-sva.c
+++ b/drivers/iommu/iommu-sva.c
@@ -12,34 +12,33 @@
static DEFINE_MUTEX(iommu_sva_lock);
/* Allocate a PASID for the mm within range (inclusive) */
-static int iommu_sva_alloc_pasid(struct mm_struct *mm, struct device *dev)
+static struct iommu_mm_data *iommu_alloc_mm_data(struct mm_struct *mm,
+ struct device *dev)
{
- ioasid_t pasid;
struct iommu_mm_data *iommu_mm;
- int ret = 0;
+ ioasid_t pasid;
+
+ lockdep_assert_held(&iommu_sva_lock);
if (!arch_pgtable_dma_compat(mm))
- return -EBUSY;
+ return ERR_PTR(-EBUSY);
- mutex_lock(&iommu_sva_lock);
+ iommu_mm = mm->iommu_mm;
/* Is a PASID already associated with this mm? */
- if (mm_valid_pasid(mm)) {
- if (mm_get_pasid(mm) >= dev->iommu->max_pasids)
- ret = -EOVERFLOW;
- goto out;
+ if (iommu_mm) {
+ if (iommu_mm->pasid >= dev->iommu->max_pasids)
+ return ERR_PTR(-EOVERFLOW);
+ return iommu_mm;
}
iommu_mm = kzalloc(sizeof(struct iommu_mm_data), GFP_KERNEL);
- if (!iommu_mm) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!iommu_mm)
+ return ERR_PTR(-ENOMEM);
pasid = iommu_alloc_global_pasid(dev);
if (pasid == IOMMU_PASID_INVALID) {
kfree(iommu_mm);
- ret = -ENOSPC;
- goto out;
+ return ERR_PTR(-ENOSPC);
}
iommu_mm->pasid = pasid;
INIT_LIST_HEAD(&iommu_mm->sva_domains);
@@ -49,11 +48,7 @@ static int iommu_sva_alloc_pasid(struct mm_struct *mm, struct device *dev)
* valid iommu_mm with uninitialized values.
*/
smp_store_release(&mm->iommu_mm, iommu_mm);
-
- ret = 0;
-out:
- mutex_unlock(&iommu_sva_lock);
- return ret;
+ return iommu_mm;
}
/**
@@ -74,23 +69,29 @@ static int iommu_sva_alloc_pasid(struct mm_struct *mm, struct device *dev)
*/
struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct *mm)
{
+ struct iommu_mm_data *iommu_mm;
struct iommu_domain *domain;
struct iommu_sva *handle;
int ret;
+ mutex_lock(&iommu_sva_lock);
+
/* Allocate mm->pasid if necessary. */
- ret = iommu_sva_alloc_pasid(mm, dev);
- if (ret)
- return ERR_PTR(ret);
+ iommu_mm = iommu_alloc_mm_data(mm, dev);
+ if (IS_ERR(iommu_mm)) {
+ ret = PTR_ERR(iommu_mm);
+ goto out_unlock;
+ }
handle = kzalloc(sizeof(*handle), GFP_KERNEL);
- if (!handle)
- return ERR_PTR(-ENOMEM);
+ if (!handle) {
+ ret = -ENOMEM;
+ goto out_unlock;
+ }
- mutex_lock(&iommu_sva_lock);
/* Search for an existing domain. */
list_for_each_entry(domain, &mm->iommu_mm->sva_domains, next) {
- ret = iommu_attach_device_pasid(domain, dev, mm_get_pasid(mm));
+ ret = iommu_attach_device_pasid(domain, dev, iommu_mm->pasid);
if (!ret) {
domain->users++;
goto out;
@@ -104,7 +105,7 @@ struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct *mm
goto out_unlock;
}
- ret = iommu_attach_device_pasid(domain, dev, mm_get_pasid(mm));
+ ret = iommu_attach_device_pasid(domain, dev, iommu_mm->pasid);
if (ret)
goto out_free_domain;
domain->users = 1;
@@ -119,10 +120,9 @@ struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct *mm
out_free_domain:
iommu_domain_free(domain);
+ kfree(handle);
out_unlock:
mutex_unlock(&iommu_sva_lock);
- kfree(handle);
-
return ERR_PTR(ret);
}
EXPORT_SYMBOL_GPL(iommu_sva_bind_device);
@@ -220,9 +220,11 @@ iommu_sva_handle_iopf(struct iommu_fault *fault, void *data)
void mm_pasid_drop(struct mm_struct *mm)
{
- if (likely(!mm_valid_pasid(mm)))
+ struct iommu_mm_data *iommu_mm = mm->iommu_mm;
+
+ if (!iommu_mm)
return;
- iommu_free_global_pasid(mm_get_pasid(mm));
- kfree(mm->iommu_mm);
+ iommu_free_global_pasid(iommu_mm->pasid);
+ kfree(iommu_mm);
}
^ permalink raw reply related [flat|nested] 17+ messages in thread* RE: [PATCH v5 5/6] iommu: Support mm PASID 1:n with sva domains
2023-10-06 18:06 ` Jason Gunthorpe
@ 2023-10-10 13:38 ` Zhang, Tina
0 siblings, 0 replies; 17+ messages in thread
From: Zhang, Tina @ 2023-10-10 13:38 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Tian, Kevin, Lu Baolu, Michael Shavit, Vasant Hegde,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org
Hi Jason,
> -----Original Message-----
> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Saturday, October 7, 2023 2:06 AM
> To: Zhang, Tina <tina.zhang@intel.com>
> Cc: Tian, Kevin <kevin.tian@intel.com>; Lu Baolu <baolu.lu@linux.intel.com>;
> Michael Shavit <mshavit@google.com>; Vasant Hegde
> <vasant.hegde@amd.com>; iommu@lists.linux.dev; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH v5 5/6] iommu: Support mm PASID 1:n with sva domains
>
> On Mon, Sep 25, 2023 at 10:38:12AM +0800, Tina Zhang wrote:
> > Each mm bound to devices gets a PASID and corresponding sva domains
> > allocated in iommu_sva_bind_device(), which are referenced by
> iommu_mm
> > field of the mm. The PASID is released in __mmdrop(), while a sva
> > domain is released when no one is using it (the reference count is
> > decremented in iommu_sva_unbind_device()). However, although sva
> > domains and their PASID are separate objects such that their own life
> > cycles could be handled independently, an enqcmd use case may require
> > releasing the PASID in releasing the mm (i.e., once a PASID is
> > allocated for a mm, it will be permanently used by the mm and won't be
> > released until the end of mm) and only allows to drop the PASID after
> > the sva domains are released. To this end, mmgrab() is called in
> > iommu_sva_domain_alloc() to increment the mm reference count and
> > mmdrop() is invoked in
> > iommu_domain_free() to decrement the mm reference count.
> >
> > Since the required info of PASID and sva domains is kept in struct
> > iommu_mm_data of a mm, use mm->iommu_mm field instead of the old
> pasid
> > field in mm struct. The sva domain list is protected by iommu_sva_lock.
> >
> > Besides, this patch removes mm_pasid_init(), as with the introduced
> > iommu_mm structure, initializing mm pasid in mm_init() is unnecessary.
> >
> > Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
> > Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
> > Signed-off-by: Tina Zhang <tina.zhang@intel.com>
> > ---
> >
> > Change in v5:
> > - Use smp_store_release() & READ_ONCE() in storing and loading mm's
> > pasid value.
> >
> > Change in v4:
> > - Rebase to v6.6-rc1.
> >
> > drivers/iommu/iommu-sva.c | 40 +++++++++++++++++++++++++++-----------
> -
> > include/linux/iommu.h | 18 +++++++++++-------
> > kernel/fork.c | 1 -
> > 3 files changed, 39 insertions(+), 20 deletions(-)
>
> I was wondering what Nicolin's issue was, didn't see anything.
>
> But I think you should incorporate this into the patch.
>
> And there is a straightforward way to move the global lock into the
> iommu_mm_data that we can explore later.
OK. Let's try it. Hope this could solve the issue reported by Nicolin.
Regards,
-Tina
^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH v5 6/6] mm: Deprecate pasid field
2023-09-25 2:38 [PATCH v5 0/6] Share sva domains with all devices bound to a mm Tina Zhang
` (4 preceding siblings ...)
2023-09-25 2:38 ` [PATCH v5 5/6] iommu: Support mm PASID 1:n with sva domains Tina Zhang
@ 2023-09-25 2:38 ` Tina Zhang
2023-10-05 18:50 ` Jason Gunthorpe
5 siblings, 1 reply; 17+ messages in thread
From: Tina Zhang @ 2023-09-25 2:38 UTC (permalink / raw)
To: Jason Gunthorpe, Kevin Tian, Lu Baolu
Cc: Michael Shavit, Vasant Hegde, iommu, linux-kernel, Tina Zhang
Drop the pasid field, as all the information needed for sva domain
management has been moved to the newly added iommu_mm field.
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
Signed-off-by: Tina Zhang <tina.zhang@intel.com>
---
include/linux/mm_types.h | 1 -
mm/init-mm.c | 3 ---
2 files changed, 4 deletions(-)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 9f4efed85f74..37f049c4b059 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -883,7 +883,6 @@ struct mm_struct {
struct work_struct async_put_work;
#ifdef CONFIG_IOMMU_SVA
- u32 pasid;
struct iommu_mm_data *iommu_mm;
#endif
#ifdef CONFIG_KSM
diff --git a/mm/init-mm.c b/mm/init-mm.c
index cfd367822cdd..24c809379274 100644
--- a/mm/init-mm.c
+++ b/mm/init-mm.c
@@ -44,9 +44,6 @@ struct mm_struct init_mm = {
#endif
.user_ns = &init_user_ns,
.cpu_bitmap = CPU_BITS_NONE,
-#ifdef CONFIG_IOMMU_SVA
- .pasid = IOMMU_PASID_INVALID,
-#endif
INIT_MM_CONTEXT(init_mm)
};
--
2.34.1
^ permalink raw reply related [flat|nested] 17+ messages in thread* Re: [PATCH v5 6/6] mm: Deprecate pasid field
2023-09-25 2:38 ` [PATCH v5 6/6] mm: Deprecate pasid field Tina Zhang
@ 2023-10-05 18:50 ` Jason Gunthorpe
0 siblings, 0 replies; 17+ messages in thread
From: Jason Gunthorpe @ 2023-10-05 18:50 UTC (permalink / raw)
To: Tina Zhang
Cc: Kevin Tian, Lu Baolu, Michael Shavit, Vasant Hegde, iommu,
linux-kernel
On Mon, Sep 25, 2023 at 10:38:13AM +0800, Tina Zhang wrote:
> Drop the pasid field, as all the information needed for sva domain
> management has been moved to the newly added iommu_mm field.
>
> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
> Signed-off-by: Tina Zhang <tina.zhang@intel.com>
> ---
> include/linux/mm_types.h | 1 -
> mm/init-mm.c | 3 ---
> 2 files changed, 4 deletions(-)
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
^ permalink raw reply [flat|nested] 17+ messages in thread