[2/5] iommu: Call helper function to get assigned pasid value
Commit Message
Use the helper function mm_get_pasid() to get the mm assigned pasid
value.
Signed-off-by: Tina Zhang <tina.zhang@intel.com>
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 12 ++++++------
drivers/iommu/intel/svm.c | 8 ++++----
drivers/iommu/iommu-sva.c | 14 +++++++-------
3 files changed, 17 insertions(+), 17 deletions(-)
Comments
On 2023/8/8 15:49, Tina Zhang wrote:
> Use the helper function mm_get_pasid() to get the mm assigned pasid
> value.
For internal iommu drivers, perhaps we should use another helper.
Something like sva_domain_get_pasid()?
Suppose that the iommu drivers should have no idea about the "mm".
Best regards,
baolu
>
> Signed-off-by: Tina Zhang <tina.zhang@intel.com>
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 12 ++++++------
> drivers/iommu/intel/svm.c | 8 ++++----
> drivers/iommu/iommu-sva.c | 14 +++++++-------
> 3 files changed, 17 insertions(+), 17 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 a5a63b1c947e..0b455654d365 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
> @@ -204,7 +204,7 @@ static void arm_smmu_mm_invalidate_range(struct mmu_notifier *mn,
> if (!(smmu_domain->smmu->features & ARM_SMMU_FEAT_BTM))
> arm_smmu_tlb_inv_range_asid(start, size, smmu_mn->cd->asid,
> PAGE_SIZE, false, 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)
> @@ -222,10 +222,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);
> @@ -279,7 +279,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;
>
> @@ -304,7 +304,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
> @@ -312,7 +312,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/intel/svm.c b/drivers/iommu/intel/svm.c
> index e95b339e9cdc..e6377cff6a93 100644
> --- a/drivers/iommu/intel/svm.c
> +++ b/drivers/iommu/intel/svm.c
> @@ -306,13 +306,13 @@ static int intel_svm_bind_mm(struct intel_iommu *iommu, struct device *dev,
> unsigned long sflags;
> int ret = 0;
>
> - svm = pasid_private_find(mm->pasid);
> + svm = pasid_private_find(mm_get_pasid(mm));
> if (!svm) {
> svm = kzalloc(sizeof(*svm), GFP_KERNEL);
> if (!svm)
> return -ENOMEM;
>
> - svm->pasid = mm->pasid;
> + svm->pasid = mm_get_pasid(mm);
> svm->mm = mm;
> INIT_LIST_HEAD_RCU(&svm->devs);
>
> @@ -350,7 +350,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, mm_get_pasid(mm),
> FLPT_DEFAULT_DID, sflags);
> if (ret)
> goto free_sdev;
> @@ -364,7 +364,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(mm_get_pasid(mm));
> kfree(svm);
> }
>
> diff --git a/drivers/iommu/iommu-sva.c b/drivers/iommu/iommu-sva.c
> index 05c0fb2acbc4..0a4a1ed40814 100644
> --- a/drivers/iommu/iommu-sva.c
> +++ b/drivers/iommu/iommu-sva.c
> @@ -28,7 +28,7 @@ static int iommu_sva_alloc_pasid(struct mm_struct *mm, ioasid_t min, ioasid_t ma
> mutex_lock(&iommu_sva_lock);
> /* Is a PASID already associated with this mm? */
> if (mm_valid_pasid(mm)) {
> - if (mm->pasid < min || mm->pasid > max)
> + if (mm_get_pasid(mm) < min || mm_get_pasid(mm) > max)
> ret = -EOVERFLOW;
> goto out;
> }
> @@ -71,7 +71,7 @@ struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct *mm
> if (!max_pasids)
> return ERR_PTR(-EOPNOTSUPP);
>
> - /* Allocate mm->pasid if necessary. */
> + /* Allocate pasid if necessary. */
> ret = iommu_sva_alloc_pasid(mm, 1, max_pasids - 1);
> if (ret)
> return ERR_PTR(ret);
> @@ -82,7 +82,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);
> @@ -101,7 +101,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;
> @@ -133,7 +133,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);
> @@ -150,7 +150,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);
>
> @@ -217,5 +217,5 @@ void mm_pasid_drop(struct mm_struct *mm)
> if (likely(!mm_valid_pasid(mm)))
> return;
>
> - ida_free(&iommu_global_pasid_ida, mm->pasid);
> + ida_free(&iommu_global_pasid_ida, mm_get_pasid(mm));
> }
> From: Baolu Lu <baolu.lu@linux.intel.com>
> Sent: Wednesday, August 9, 2023 8:22 AM
>
> On 2023/8/8 15:49, Tina Zhang wrote:
> > Use the helper function mm_get_pasid() to get the mm assigned pasid
> > value.
>
> For internal iommu drivers, perhaps we should use another helper.
> Something like sva_domain_get_pasid()?
>
> Suppose that the iommu drivers should have no idea about the "mm".
>
Aren't all touched functions accept a struct mm_struct pointer?
On 2023/8/9 17:49, Tian, Kevin wrote:
>> From: Baolu Lu <baolu.lu@linux.intel.com>
>> Sent: Wednesday, August 9, 2023 8:22 AM
>>
>> On 2023/8/8 15:49, Tina Zhang wrote:
>>> Use the helper function mm_get_pasid() to get the mm assigned pasid
>>> value.
>>
>> For internal iommu drivers, perhaps we should use another helper.
>> Something like sva_domain_get_pasid()?
>>
>> Suppose that the iommu drivers should have no idea about the "mm".
>>
>
> Aren't all touched functions accept a struct mm_struct pointer?
In the end we should remove all mm reference in the individual drivers.
The drivers only need to know what they need to know. All mm-aware code
should eventually be moved to the core.
For now, at least we should avoid using mm in the set/remove_dev_pasid
code path. Later, once we complete consolidating mm notification in the
core, drivers will have no need to use "mm" anymore.
Best regards,
baolu
On Wed, Aug 09, 2023 at 09:49:16AM +0000, Tian, Kevin wrote:
> > From: Baolu Lu <baolu.lu@linux.intel.com>
> > Sent: Wednesday, August 9, 2023 8:22 AM
> >
> > On 2023/8/8 15:49, Tina Zhang wrote:
> > > Use the helper function mm_get_pasid() to get the mm assigned pasid
> > > value.
> >
> > For internal iommu drivers, perhaps we should use another helper.
> > Something like sva_domain_get_pasid()?
> >
> > Suppose that the iommu drivers should have no idea about the "mm".
> >
>
> Aren't all touched functions accept a struct mm_struct pointer?
It is wrong for the driver to even ask this question.
Domains, regardless of what they are, get attached to PASIDs. Maybe
many PASIDs, driver doesn't get to care. SVA isn't special. Stop
making it special.
The driver should rely on there being exactly one iommu_domain for SVA
per mm so it can hang the mm_notifier off the iommu_domain
But otherwise invalidation for a SVA domain should be *exactly the
same flow* as invalidation for a paging domain. It iterates over the
attachments and generates the correct list of PASIDs and ATCs.
Jason
On Wed, Aug 09, 2023 at 06:58:15PM +0800, Baolu Lu wrote:
> On 2023/8/9 17:49, Tian, Kevin wrote:
> > > From: Baolu Lu <baolu.lu@linux.intel.com>
> > > Sent: Wednesday, August 9, 2023 8:22 AM
> > >
> > > On 2023/8/8 15:49, Tina Zhang wrote:
> > > > Use the helper function mm_get_pasid() to get the mm assigned pasid
> > > > value.
> > >
> > > For internal iommu drivers, perhaps we should use another helper.
> > > Something like sva_domain_get_pasid()?
> > >
> > > Suppose that the iommu drivers should have no idea about the "mm".
> > >
> >
> > Aren't all touched functions accept a struct mm_struct pointer?
>
> In the end we should remove all mm reference in the individual drivers.
> The drivers only need to know what they need to know. All mm-aware code
> should eventually be moved to the core.
>
> For now, at least we should avoid using mm in the set/remove_dev_pasid
> code path. Later, once we complete consolidating mm notification in the
> core, drivers will have no need to use "mm" anymore.
I'm not sure how this will play out...
We don't want extra function indirections here so ultimately the
driver needs to hook the arch_invalidate_range() in the mm_notifier
with its own function.
The core could put the mm_notifier in a common iommu_domain_sva struct
and it could stick in the driver's invalidate ops, that would be a
nice simplification (and discourage drivers from doing the crazy
things they are currently doing)
Jason
On 2023/8/9 22:48, Jason Gunthorpe wrote:
> On Wed, Aug 09, 2023 at 06:58:15PM +0800, Baolu Lu wrote:
>> On 2023/8/9 17:49, Tian, Kevin wrote:
>>>> From: Baolu Lu <baolu.lu@linux.intel.com>
>>>> Sent: Wednesday, August 9, 2023 8:22 AM
>>>>
>>>> On 2023/8/8 15:49, Tina Zhang wrote:
>>>>> Use the helper function mm_get_pasid() to get the mm assigned pasid
>>>>> value.
>>>>
>>>> For internal iommu drivers, perhaps we should use another helper.
>>>> Something like sva_domain_get_pasid()?
>>>>
>>>> Suppose that the iommu drivers should have no idea about the "mm".
>>>>
>>>
>>> Aren't all touched functions accept a struct mm_struct pointer?
>>
>> In the end we should remove all mm reference in the individual drivers.
>> The drivers only need to know what they need to know. All mm-aware code
>> should eventually be moved to the core.
>>
>> For now, at least we should avoid using mm in the set/remove_dev_pasid
>> code path. Later, once we complete consolidating mm notification in the
>> core, drivers will have no need to use "mm" anymore.
>
> I'm not sure how this will play out...
>
> We don't want extra function indirections here so ultimately the
> driver needs to hook the arch_invalidate_range() in the mm_notifier
> with its own function.
Agreed. Given the mm notification callback is a performance path, an
extra indirection call here is not good.
>
> The core could put the mm_notifier in a common iommu_domain_sva struct
> and it could stick in the driver's invalidate ops, that would be a
> nice simplification (and discourage drivers from doing the crazy
> things they are currently doing)
Yes. So the iommu driver can retrieve the sva domain from struct
mmu_notifier. The callback implementation will still be domain centric.
Hence, there will be no need to use mm.
Best regards,
baolu
> From: Jason Gunthorpe <jgg@ziepe.ca>
> Sent: Wednesday, August 9, 2023 8:35 PM
>
> On Wed, Aug 09, 2023 at 09:49:16AM +0000, Tian, Kevin wrote:
> > > From: Baolu Lu <baolu.lu@linux.intel.com>
> > > Sent: Wednesday, August 9, 2023 8:22 AM
> > >
> > > On 2023/8/8 15:49, Tina Zhang wrote:
> > > > Use the helper function mm_get_pasid() to get the mm assigned pasid
> > > > value.
> > >
> > > For internal iommu drivers, perhaps we should use another helper.
> > > Something like sva_domain_get_pasid()?
> > >
> > > Suppose that the iommu drivers should have no idea about the "mm".
> > >
> >
> > Aren't all touched functions accept a struct mm_struct pointer?
>
> It is wrong for the driver to even ask this question.
>
> Domains, regardless of what they are, get attached to PASIDs. Maybe
> many PASIDs, driver doesn't get to care. SVA isn't special. Stop
> making it special.
Agree. I didn't think that far for what this series intends to achieve.
>
> The driver should rely on there being exactly one iommu_domain for SVA
> per mm so it can hang the mm_notifier off the iommu_domain
I'm confused. Isn't this series trying to allow multiple domains per mm?
>
> But otherwise invalidation for a SVA domain should be *exactly the
> same flow* as invalidation for a paging domain. It iterates over the
> attachments and generates the correct list of PASIDs and ATCs.
>
> Jason
On Thu, Aug 10, 2023 at 09:37:09AM +0800, Baolu Lu wrote:
> > The core could put the mm_notifier in a common iommu_domain_sva struct
> > and it could stick in the driver's invalidate ops, that would be a
> > nice simplification (and discourage drivers from doing the crazy
> > things they are currently doing)
>
> Yes. So the iommu driver can retrieve the sva domain from struct
> mmu_notifier. The callback implementation will still be domain centric.
> Hence, there will be no need to use mm.
Remember the driver always needs the mm as it has to extract the page
table address from it.
At the end of the day installing the notifier is a single call in the
SVA alloc op, so it may not be worth optimizing beyond allowing
drivers to do it in their SVA alloc op.
Jason
On Thu, Aug 10, 2023 at 07:52:52AM +0000, Tian, Kevin wrote:
> > The driver should rely on there being exactly one iommu_domain for SVA
> > per mm so it can hang the mm_notifier off the iommu_domain
>
> I'm confused. Isn't this series trying to allow multiple domains per mm?
It is doing both.
The main objective is to allow de-duplicating the SVA domains in the
core code. The driver should be able to assume one SVA domain per
instance, or even one SVA domain per compatible instance. The driver
should not do any de-duplication.
But we can't just store a single iommu_domain in the mm_struct - we
have the same problem as iommufd and we need to create more domains if
the domains we already have are incompatible with the device.
Arguably this should not happen, and in any sane configuration we
should have only 1 type of IOMMU driver that needs only 1 SVA domain.
But right now things like SMMUv3 have problems crossing domains across
instances, so we could have one SVA domain per IOMMU instance until
that is fixed.
Jason
> From: Jason Gunthorpe <jgg@ziepe.ca>
> Sent: Friday, August 11, 2023 12:37 AM
>
> On Thu, Aug 10, 2023 at 07:52:52AM +0000, Tian, Kevin wrote:
>
> > > The driver should rely on there being exactly one iommu_domain for SVA
> > > per mm so it can hang the mm_notifier off the iommu_domain
> >
> > I'm confused. Isn't this series trying to allow multiple domains per mm?
>
> It is doing both.
>
> The main objective is to allow de-duplicating the SVA domains in the
> core code. The driver should be able to assume one SVA domain per
> instance, or even one SVA domain per compatible instance. The driver
> should not do any de-duplication.
>
> But we can't just store a single iommu_domain in the mm_struct - we
> have the same problem as iommufd and we need to create more domains if
> the domains we already have are incompatible with the device.
>
> Arguably this should not happen, and in any sane configuration we
> should have only 1 type of IOMMU driver that needs only 1 SVA domain.
>
> But right now things like SMMUv3 have problems crossing domains across
> instances, so we could have one SVA domain per IOMMU instance until
> that is fixed.
>
Thanks for the explanation. Tina, please include this information in your
next version so others can easily understand the motivation of introducing
multiple sva domains per mm.
@@ -204,7 +204,7 @@ static void arm_smmu_mm_invalidate_range(struct mmu_notifier *mn,
if (!(smmu_domain->smmu->features & ARM_SMMU_FEAT_BTM))
arm_smmu_tlb_inv_range_asid(start, size, smmu_mn->cd->asid,
PAGE_SIZE, false, 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)
@@ -222,10 +222,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);
@@ -279,7 +279,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;
@@ -304,7 +304,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
@@ -312,7 +312,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 */
@@ -306,13 +306,13 @@ static int intel_svm_bind_mm(struct intel_iommu *iommu, struct device *dev,
unsigned long sflags;
int ret = 0;
- svm = pasid_private_find(mm->pasid);
+ svm = pasid_private_find(mm_get_pasid(mm));
if (!svm) {
svm = kzalloc(sizeof(*svm), GFP_KERNEL);
if (!svm)
return -ENOMEM;
- svm->pasid = mm->pasid;
+ svm->pasid = mm_get_pasid(mm);
svm->mm = mm;
INIT_LIST_HEAD_RCU(&svm->devs);
@@ -350,7 +350,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, mm_get_pasid(mm),
FLPT_DEFAULT_DID, sflags);
if (ret)
goto free_sdev;
@@ -364,7 +364,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(mm_get_pasid(mm));
kfree(svm);
}
@@ -28,7 +28,7 @@ static int iommu_sva_alloc_pasid(struct mm_struct *mm, ioasid_t min, ioasid_t ma
mutex_lock(&iommu_sva_lock);
/* Is a PASID already associated with this mm? */
if (mm_valid_pasid(mm)) {
- if (mm->pasid < min || mm->pasid > max)
+ if (mm_get_pasid(mm) < min || mm_get_pasid(mm) > max)
ret = -EOVERFLOW;
goto out;
}
@@ -71,7 +71,7 @@ struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct *mm
if (!max_pasids)
return ERR_PTR(-EOPNOTSUPP);
- /* Allocate mm->pasid if necessary. */
+ /* Allocate pasid if necessary. */
ret = iommu_sva_alloc_pasid(mm, 1, max_pasids - 1);
if (ret)
return ERR_PTR(ret);
@@ -82,7 +82,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);
@@ -101,7 +101,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;
@@ -133,7 +133,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);
@@ -150,7 +150,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);
@@ -217,5 +217,5 @@ void mm_pasid_drop(struct mm_struct *mm)
if (likely(!mm_valid_pasid(mm)))
return;
- ida_free(&iommu_global_pasid_ida, mm->pasid);
+ ida_free(&iommu_global_pasid_ida, mm_get_pasid(mm));
}