| Message ID | 9-v1-e289ca9121be+2be-smmuv3_newapi_p1_jgg@nvidia.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Update SMMUv3 to the modern iommu API (part 1/2) | expand |
On Wed, Oct 11, 2023 at 8:33 AM Jason Gunthorpe <jgg@nvidia.com> wrote: > > The BTM support wants to be able to change the ASID of any smmu_domain. > When it goes to do this it holds the arm_smmu_asid_lock and iterates over > the target domain's devices list. > > During attach of a S1 domain we must ensure that the devices list and > CD are in sync, otherwise we could miss CD updates or a parallel CD update > could push an out of date CD. > > This is pretty complicated, and works today because arm_smmu_detach_dev() > remove the CD table from the STE before working on the CD entries. > > The next patch will allow the CD table to remain in the STE so solve this > racy by holding the lock for a longer period. The lock covers both of the > changes to the device list and the CD table entries. > > Move arm_smmu_detach_dev() till after we have initialized the domain so > the lock can be held for less time. > > Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> > --- > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 24 ++++++++++++--------- > 1 file changed, 14 insertions(+), 10 deletions(-) > > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > index 2c06d3e3abe2b1..a29421f133a3c0 100644 > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > @@ -2535,8 +2535,6 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev) > return -EBUSY; > } > > - arm_smmu_detach_dev(master); > - > mutex_lock(&smmu_domain->init_mutex); > > if (!smmu_domain->smmu) { > @@ -2549,7 +2547,17 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev) > > mutex_unlock(&smmu_domain->init_mutex); > if (ret) > - return ret; > + goto out_unlock; Oh, missed this earlier but on a second look the asid_lock isn't grabbed here yet so this should stay as return ret. > + > + /* > + * Prevent arm_smmu_share_asid() from trying to change the ASID > + * of either the old or new domain while we are working on it. > + * This allows the STE and the smmu_domain->devices list to > + * be inconsistent during this routine. > + */ > + mutex_lock(&arm_smmu_asid_lock); > + > + arm_smmu_detach_dev(master); > > master->domain = smmu_domain; > > @@ -2576,13 +2584,7 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev) > } > } > > - /* > - * Prevent SVA from concurrently modifying the CD or writing to > - * the CD entry > - */ > - mutex_lock(&arm_smmu_asid_lock); > ret = arm_smmu_write_ctx_desc(master, IOMMU_NO_PASID, &smmu_domain->cd); > - mutex_unlock(&arm_smmu_asid_lock); > if (ret) { > master->domain = NULL; > goto out_list_del; > @@ -2592,13 +2594,15 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev) > arm_smmu_install_ste_for_dev(master); > > arm_smmu_enable_ats(master); > - return 0; > + goto out_unlock; > > out_list_del: > spin_lock_irqsave(&smmu_domain->devices_lock, flags); > list_del(&master->domain_head); > spin_unlock_irqrestore(&smmu_domain->devices_lock, flags); > > +out_unlock: > + mutex_unlock(&arm_smmu_asid_lock); > return ret; > } > > -- > 2.42.0 >
On Tue, Oct 24, 2023 at 10:44 AM Michael Shavit <mshavit@google.com> wrote: > > On Wed, Oct 11, 2023 at 8:33 AM Jason Gunthorpe <jgg@nvidia.com> wrote: > > > > The BTM support wants to be able to change the ASID of any smmu_domain. > > When it goes to do this it holds the arm_smmu_asid_lock and iterates over > > the target domain's devices list. > > > > During attach of a S1 domain we must ensure that the devices list and > > CD are in sync, otherwise we could miss CD updates or a parallel CD update > > could push an out of date CD. > > > > This is pretty complicated, and works today because arm_smmu_detach_dev() > > remove the CD table from the STE before working on the CD entries. > > > > The next patch will allow the CD table to remain in the STE so solve this > > racy by holding the lock for a longer period. The lock covers both of the > > changes to the device list and the CD table entries. > > > > Move arm_smmu_detach_dev() till after we have initialized the domain so > > the lock can be held for less time. > > > > Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> > > --- > > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 24 ++++++++++++--------- > > 1 file changed, 14 insertions(+), 10 deletions(-) > > > > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > > index 2c06d3e3abe2b1..a29421f133a3c0 100644 > > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > > @@ -2535,8 +2535,6 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev) > > return -EBUSY; > > } > > > > - arm_smmu_detach_dev(master); > > - > > mutex_lock(&smmu_domain->init_mutex); > > > > if (!smmu_domain->smmu) { > > @@ -2549,7 +2547,17 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev) > > > > mutex_unlock(&smmu_domain->init_mutex); > > if (ret) > > - return ret; > > + goto out_unlock; > > Oh, missed this earlier but on a second look the asid_lock isn't > grabbed here yet so this should stay as return ret. > Guess you must have noticed it too since it's fixed in patch 09 of the second series :) .
On Tue, Oct 24, 2023 at 10:44:36AM +0800, Michael Shavit wrote: > > @@ -2549,7 +2547,17 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev) > > > > mutex_unlock(&smmu_domain->init_mutex); > > if (ret) > > - return ret; > > + goto out_unlock; > > Oh, missed this earlier but on a second look the asid_lock isn't > grabbed here yet so this should stay as return ret. Yep, there is a hunk in a later patch fixing this, I moved it here Thanks, Jason
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c index 2c06d3e3abe2b1..a29421f133a3c0 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c @@ -2535,8 +2535,6 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev) return -EBUSY; } - arm_smmu_detach_dev(master); - mutex_lock(&smmu_domain->init_mutex); if (!smmu_domain->smmu) { @@ -2549,7 +2547,17 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev) mutex_unlock(&smmu_domain->init_mutex); if (ret) - return ret; + goto out_unlock; + + /* + * Prevent arm_smmu_share_asid() from trying to change the ASID + * of either the old or new domain while we are working on it. + * This allows the STE and the smmu_domain->devices list to + * be inconsistent during this routine. + */ + mutex_lock(&arm_smmu_asid_lock); + + arm_smmu_detach_dev(master); master->domain = smmu_domain; @@ -2576,13 +2584,7 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev) } } - /* - * Prevent SVA from concurrently modifying the CD or writing to - * the CD entry - */ - mutex_lock(&arm_smmu_asid_lock); ret = arm_smmu_write_ctx_desc(master, IOMMU_NO_PASID, &smmu_domain->cd); - mutex_unlock(&arm_smmu_asid_lock); if (ret) { master->domain = NULL; goto out_list_del; @@ -2592,13 +2594,15 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev) arm_smmu_install_ste_for_dev(master); arm_smmu_enable_ats(master); - return 0; + goto out_unlock; out_list_del: spin_lock_irqsave(&smmu_domain->devices_lock, flags); list_del(&master->domain_head); spin_unlock_irqrestore(&smmu_domain->devices_lock, flags); +out_unlock: + mutex_unlock(&arm_smmu_asid_lock); return ret; }
The BTM support wants to be able to change the ASID of any smmu_domain. When it goes to do this it holds the arm_smmu_asid_lock and iterates over the target domain's devices list. During attach of a S1 domain we must ensure that the devices list and CD are in sync, otherwise we could miss CD updates or a parallel CD update could push an out of date CD. This is pretty complicated, and works today because arm_smmu_detach_dev() remove the CD table from the STE before working on the CD entries. The next patch will allow the CD table to remain in the STE so solve this racy by holding the lock for a longer period. The lock covers both of the changes to the device list and the CD table entries. Move arm_smmu_detach_dev() till after we have initialized the domain so the lock can be held for less time. Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 24 ++++++++++++--------- 1 file changed, 14 insertions(+), 10 deletions(-)