[GIT PULL] dma-mapping fixes for 5.19
[I really wanted to send these before -rc1, but the fact that today is a public holiday here really confused me and messed up my schedule] The following changes since commit 4a37f3dd9a83186cb88d44808ab35b78375082c9: dma-direct: don't over-decrypt memory (2022-05-23 15:25:40 +0200) are available in the Git repository at: git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-5.19-2022-06-06 for you to fetch changes up to e15db62bc5648ab459a570862f654e787c498faf: swiotlb: fix setting ->force_bounce (2022-06-02 07:17:59 +0200) dma-mapping fixes for Linux 5.19 - fix a regressin in setting swiotlb ->force_bounce (me) - make dma-debug less chatty (Rob Clark) Christoph Hellwig (1): swiotlb: fix setting ->force_bounce Rob Clark (1): dma-debug: make things less spammy under memory pressure kernel/dma/debug.c | 2 +- kernel/dma/swiotlb.c | 14 ++ 2 files changed, 7 insertions(+), 9 deletions(-) ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 4/5] vfio/iommu_type1: Clean up update_dirty_scope in detach_group()
All devices in emulated_iommu_groups have pinned_page_dirty_scope
set, so the update_dirty_scope in the first list_for_each_entry
is always false. Clean it up, and move the "if update_dirty_scope"
part from the detach_group_done routine to the domain_list part.
Rename the "detach_group_done" goto label accordingly.
Suggested-by: Jason Gunthorpe
Signed-off-by: Nicolin Chen
---
drivers/vfio/vfio_iommu_type1.c | 27 ---
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index f4e3b423a453..b45b1cc118ef 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -2463,14 +2463,12 @@ static void vfio_iommu_type1_detach_group(void
*iommu_data,
struct vfio_iommu *iommu = iommu_data;
struct vfio_domain *domain;
struct vfio_iommu_group *group;
- bool update_dirty_scope = false;
LIST_HEAD(iova_copy);
mutex_lock(&iommu->lock);
list_for_each_entry(group, &iommu->emulated_iommu_groups, next) {
if (group->iommu_group != iommu_group)
continue;
- update_dirty_scope = !group->pinned_page_dirty_scope;
list_del(&group->next);
kfree(group);
@@ -2479,7 +2477,7 @@ static void vfio_iommu_type1_detach_group(void
*iommu_data,
WARN_ON(iommu->notifier.head);
vfio_iommu_unmap_unpin_all(iommu);
}
- goto detach_group_done;
+ goto out_unlock;
}
/*
@@ -2495,9 +2493,7 @@ static void vfio_iommu_type1_detach_group(void
*iommu_data,
continue;
iommu_detach_group(domain->domain, group->iommu_group);
- update_dirty_scope = !group->pinned_page_dirty_scope;
list_del(&group->next);
- kfree(group);
/*
* Group ownership provides privilege, if the group list is
* empty, the domain goes away. If it's the last domain with
@@ -2519,7 +2515,17 @@ static void vfio_iommu_type1_detach_group(void
*iommu_data,
kfree(domain);
vfio_iommu_aper_expand(iommu, &iova_copy);
vfio_update_pgsize_bitmap(iommu);
+ /*
+* Removal of a group without dirty tracking may allow
+* the iommu scope to be promoted.
+*/
+ if (!group->pinned_page_dirty_scope) {
+ iommu->num_non_pinned_groups--;
+ if (iommu->dirty_page_tracking)
+ vfio_iommu_populate_bitmap_full(iommu);
+ }
}
+ kfree(group);
break;
}
@@ -2528,16 +2534,7 @@ static void vfio_iommu_type1_detach_group(void
*iommu_data,
else
vfio_iommu_iova_free(&iova_copy);
-detach_group_done:
- /*
-* Removal of a group without dirty tracking may allow the iommu scope
-* to be promoted.
-*/
- if (update_dirty_scope) {
- iommu->num_non_pinned_groups--;
- if (iommu->dirty_page_tracking)
- vfio_iommu_populate_bitmap_full(iommu);
- }
+out_unlock:
mutex_unlock(&iommu->lock);
}
--
2.17.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 5/5] vfio/iommu_type1: Simplify group attachment
Un-inline the domain specific logic from the attach/detach_group ops into
two paired functions vfio_iommu_alloc_attach_domain() and
vfio_iommu_detach_destroy_domain() that strictly deal with creating and
destroying struct vfio_domains.
Add the logic to check for EMEDIUMTYPE return code of iommu_attach_group()
and avoid the extra domain allocations and attach/detach sequences of the
old code. This allows properly detecting an actual attach error, like
-ENOMEM, vs treating all attach errors as an incompatible domain.
Remove the duplicated domain->ops comparison that is taken care of in the
IOMMU core.
Co-developed-by: Jason Gunthorpe
Signed-off-by: Jason Gunthorpe
Signed-off-by: Nicolin Chen
---
drivers/vfio/vfio_iommu_type1.c | 306 +---
1 file changed, 161 insertions(+), 145 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index b45b1cc118ef..c6f937e1d71f 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -86,6 +86,7 @@ struct vfio_domain {
struct list_headgroup_list;
boolfgsp : 1; /* Fine-grained super pages */
boolenforce_cache_coherency : 1;
+ boolmsi_cookie : 1;
};
struct vfio_dma {
@@ -2153,12 +2154,161 @@ static void vfio_iommu_iova_insert_copy(struct
vfio_iommu *iommu,
list_splice_tail(iova_copy, iova);
}
+static struct vfio_domain *
+vfio_iommu_alloc_attach_domain(struct bus_type *bus, struct vfio_iommu *iommu,
+ struct vfio_iommu_group *group)
+{
+ struct iommu_domain *new_domain;
+ struct vfio_domain *domain;
+ int ret = 0;
+
+ /* Try to match an existing compatible domain */
+ list_for_each_entry (domain, &iommu->domain_list, next) {
+ ret = iommu_attach_group(domain->domain, group->iommu_group);
+ if (ret == -EMEDIUMTYPE)
+ continue;
+ if (ret)
+ return ERR_PTR(ret);
+ list_add(&group->next, &domain->group_list);
+ return domain;
+ }
+
+ new_domain = iommu_domain_alloc(bus);
+ if (!new_domain)
+ return ERR_PTR(-EIO);
+
+ if (iommu->nesting) {
+ ret = iommu_enable_nesting(new_domain);
+ if (ret)
+ goto out_free_iommu_domain;
+ }
+
+ ret = iommu_attach_group(new_domain, group->iommu_group);
+ if (ret)
+ goto out_free_iommu_domain;
+
+ domain = kzalloc(sizeof(*domain), GFP_KERNEL);
+ if (!domain) {
+ ret = -ENOMEM;
+ goto out_detach;
+ }
+
+ domain->domain = new_domain;
+ vfio_test_domain_fgsp(domain);
+
+ /*
+* If the IOMMU can block non-coherent operations (ie PCIe TLPs with
+* no-snoop set) then VFIO always turns this feature on because on Intel
+* platforms it optimizes KVM to disable wbinvd emulation.
+*/
+ if (new_domain->ops->enforce_cache_coherency)
+ domain->enforce_cache_coherency =
+ new_domain->ops->enforce_cache_coherency(new_domain);
+
+ /* replay mappings on new domains */
+ ret = vfio_iommu_replay(iommu, domain);
+ if (ret)
+ goto out_free_domain;
+
+ /*
+* An iommu backed group can dirty memory directly and therefore
+* demotes the iommu scope until it declares itself dirty tracking
+* capable via the page pinning interface.
+*/
+ iommu->num_non_pinned_groups++;
+
+ INIT_LIST_HEAD(&domain->group_list);
+ list_add(&group->next, &domain->group_list);
+ list_add(&domain->next, &iommu->domain_list);
+ vfio_update_pgsize_bitmap(iommu);
+ return domain;
+
+out_free_domain:
+ kfree(domain);
+out_detach:
+ iommu_detach_group(domain->domain, group->iommu_group);
+out_free_iommu_domain:
+ iommu_domain_free(new_domain);
+ return ERR_PTR(ret);
+}
+
+static void vfio_iommu_unmap_unpin_all(struct vfio_iommu *iommu)
+{
+ struct rb_node *node;
+
+ while ((node = rb_first(&iommu->dma_list)))
+ vfio_remove_dma(iommu, rb_entry(node, struct vfio_dma, node));
+}
+
+static void vfio_iommu_unmap_unpin_reaccount(struct vfio_iommu *iommu)
+{
+ struct rb_node *n, *p;
+
+ n = rb_first(&iommu->dma_list);
+ for (; n; n = rb_next(n)) {
+ struct vfio_dma *dma;
+ long locked = 0, unlocked = 0;
+
+ dma = rb_entry(n, struct vfio_dma, node);
+ unlocked += vfio_unmap_unpin(iommu, dma, false);
+ p = rb_first(&dma->pfn_list);
+ for (; p; p = rb_next(p)) {
+ struct vfio_pfn *vpfn = rb_entry(p, struct vfio_pfn,
+node);
+
+
[PATCH 3/5] vfio/iommu_type1: Prefer to reuse domains vs match enforced cache coherency
From: Jason Gunthorpe
The KVM mechanism for controlling wbinvd is only triggered during
kvm_vfio_group_add(), meaning it is a one-shot test done once the devices
are setup.
So, there is no value in trying to push a device that could do enforced
cache coherency to a dedicated domain vs re-using an existing domain since
KVM won't be able to take advantage of it. This just wastes domain memory.
Simplify this code and eliminate the test. This removes the only logic
that needed to have a dummy domain attached prior to searching for a
matching domain and simplifies the next patches.
If someday we want to try and optimize this further the better approach is
to update the Intel driver so that enforce_cache_coherency() can work on a
domain that already has IOPTEs and then call the enforce_cache_coherency()
after detaching a device from a domain to upgrade the whole domain to
enforced cache coherency mode.
Signed-off-by: Jason Gunthorpe
Signed-off-by: Nicolin Chen
---
drivers/vfio/vfio_iommu_type1.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index c13b9290e357..f4e3b423a453 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -2285,9 +2285,7 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
* testing if they're on the same bus_type.
*/
list_for_each_entry(d, &iommu->domain_list, next) {
- if (d->domain->ops == domain->domain->ops &&
- d->enforce_cache_coherency ==
- domain->enforce_cache_coherency) {
+ if (d->domain->ops == domain->domain->ops) {
iommu_detach_group(domain->domain, group->iommu_group);
if (!iommu_attach_group(d->domain,
group->iommu_group)) {
--
2.17.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 2/5] iommu: Ensure device has the same iommu_ops as the domain
The core code should not call an iommu driver op with a struct device
parameter unless it knows that the dev_iommu_priv_get() for that struct
device was setup by the same driver. Otherwise in a mixed driver system
the iommu_priv could be casted to the wrong type.
Store the iommu_ops pointer in the iommu_domain and use it as a check to
validate that the struct device is correct before invoking any domain op
that accepts a struct device.
This allows removing the check of the domain op equality in VFIO.
Co-developed-by: Jason Gunthorpe
Signed-off-by: Jason Gunthorpe
Signed-off-by: Nicolin Chen
---
drivers/iommu/amd/iommu.c | 1 +
drivers/iommu/apple-dart.c | 1 +
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 1 +
drivers/iommu/arm/arm-smmu/arm-smmu.c | 1 +
drivers/iommu/arm/arm-smmu/qcom_iommu.c | 1 +
drivers/iommu/exynos-iommu.c| 1 +
drivers/iommu/fsl_pamu_domain.c | 1 +
drivers/iommu/intel/iommu.c | 1 +
drivers/iommu/iommu.c | 4
drivers/iommu/ipmmu-vmsa.c | 1 +
drivers/iommu/msm_iommu.c | 1 +
drivers/iommu/mtk_iommu.c | 1 +
drivers/iommu/mtk_iommu_v1.c| 1 +
drivers/iommu/omap-iommu.c | 1 +
drivers/iommu/rockchip-iommu.c | 1 +
drivers/iommu/s390-iommu.c | 1 +
drivers/iommu/sprd-iommu.c | 1 +
drivers/iommu/sun50i-iommu.c| 1 +
drivers/iommu/tegra-gart.c | 1 +
drivers/iommu/tegra-smmu.c | 1 +
drivers/iommu/virtio-iommu.c| 1 +
include/linux/iommu.h | 2 ++
22 files changed, 26 insertions(+)
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index ad499658a6b6..679f7a265013 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -2285,6 +2285,7 @@ const struct iommu_ops amd_iommu_ops = {
.pgsize_bitmap = AMD_IOMMU_PGSIZES,
.def_domain_type = amd_iommu_def_domain_type,
.default_domain_ops = &(const struct iommu_domain_ops) {
+ .iommu_ops = &amd_iommu_ops,
.attach_dev = amd_iommu_attach_device,
.detach_dev = amd_iommu_detach_device,
.map= amd_iommu_map,
diff --git a/drivers/iommu/apple-dart.c b/drivers/iommu/apple-dart.c
index e58dc310afd7..3d36d9a12aa7 100644
--- a/drivers/iommu/apple-dart.c
+++ b/drivers/iommu/apple-dart.c
@@ -775,6 +775,7 @@ static const struct iommu_ops apple_dart_iommu_ops = {
.pgsize_bitmap = -1UL, /* Restricted during dart probe */
.owner = THIS_MODULE,
.default_domain_ops = &(const struct iommu_domain_ops) {
+ .iommu_ops = &apple_dart_iommu_ops,
.attach_dev = apple_dart_attach_dev,
.detach_dev = apple_dart_detach_dev,
.map_pages = apple_dart_map_pages,
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 6c393cd84925..471ceb60427c 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -2859,6 +2859,7 @@ static struct iommu_ops arm_smmu_ops = {
.pgsize_bitmap = -1UL, /* Restricted during device attach */
.owner = THIS_MODULE,
.default_domain_ops = &(const struct iommu_domain_ops) {
+ .iommu_ops = &arm_smmu_ops,
.attach_dev = arm_smmu_attach_dev,
.map_pages = arm_smmu_map_pages,
.unmap_pages= arm_smmu_unmap_pages,
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c
b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index 2ed3594f384e..52c2589a4deb 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -1597,6 +1597,7 @@ static struct iommu_ops arm_smmu_ops = {
.pgsize_bitmap = -1UL, /* Restricted during device attach */
.owner = THIS_MODULE,
.default_domain_ops = &(const struct iommu_domain_ops) {
+ .iommu_ops = &arm_smmu_ops,
.attach_dev = arm_smmu_attach_dev,
.map_pages = arm_smmu_map_pages,
.unmap_pages= arm_smmu_unmap_pages,
diff --git a/drivers/iommu/arm/arm-smmu/qcom_iommu.c
b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
index a8b63b855ffb..8806a621f81e 100644
--- a/drivers/iommu/arm/arm-smmu/qcom_iommu.c
+++ b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
@@ -596,6 +596,7 @@ static const struct iommu_ops qcom_iommu_ops = {
.of_xlate = qcom_iommu_of_xlate,
.pgsize_bitmap = SZ_4K | SZ_64K | SZ_1M | SZ_16M,
.default_domain_ops = &(const struct iommu_domain_ops) {
+ .iommu_ops = &qcom_iommu
[PATCH 1/5] iommu: Return -EMEDIUMTYPE for incompatible domain and device/group
Cases like VFIO wish to attach a device to an existing domain that was
not allocated specifically from the device. This raises a condition
where the IOMMU driver can fail the domain attach because the domain and
device are incompatible with each other.
This is a soft failure that can be resolved by using a different domain.
Provide a dedicated errno from the IOMMU driver during attach that the
reason attached failed is because of domain incompatability. EMEDIUMTYPE
is chosen because it is never used within the iommu subsystem today and
evokes a sense that the 'medium' aka the domain is incompatible.
VFIO can use this to know attach is a soft failure and it should continue
searching. Otherwise the attach will be a hard failure and VFIO will
return the code to userspace.
Update all drivers to return EMEDIUMTYPE in their failure paths that are
related to domain incompatability.
Add kdocs describing this behavior.
Suggested-by: Jason Gunthorpe
Signed-off-by: Nicolin Chen
---
drivers/iommu/amd/iommu.c | 2 +-
drivers/iommu/apple-dart.c | 4 ++--
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 6 +++---
drivers/iommu/arm/arm-smmu/qcom_iommu.c | 2 +-
drivers/iommu/intel/iommu.c | 4 ++--
drivers/iommu/iommu.c | 22 +
drivers/iommu/ipmmu-vmsa.c | 2 +-
drivers/iommu/omap-iommu.c | 2 +-
drivers/iommu/virtio-iommu.c| 2 +-
9 files changed, 34 insertions(+), 12 deletions(-)
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index 840831d5d2ad..ad499658a6b6 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -1662,7 +1662,7 @@ static int attach_device(struct device *dev,
if (domain->flags & PD_IOMMUV2_MASK) {
struct iommu_domain *def_domain = iommu_get_dma_domain(dev);
- ret = -EINVAL;
+ ret = -EMEDIUMTYPE;
if (def_domain->type != IOMMU_DOMAIN_IDENTITY)
goto out;
diff --git a/drivers/iommu/apple-dart.c b/drivers/iommu/apple-dart.c
index 8af0242a90d9..e58dc310afd7 100644
--- a/drivers/iommu/apple-dart.c
+++ b/drivers/iommu/apple-dart.c
@@ -495,10 +495,10 @@ static int apple_dart_attach_dev(struct iommu_domain
*domain,
if (cfg->stream_maps[0].dart->force_bypass &&
domain->type != IOMMU_DOMAIN_IDENTITY)
- return -EINVAL;
+ return -EMEDIUMTYPE;
if (!cfg->stream_maps[0].dart->supports_bypass &&
domain->type == IOMMU_DOMAIN_IDENTITY)
- return -EINVAL;
+ return -EMEDIUMTYPE;
ret = apple_dart_finalize_domain(domain, cfg);
if (ret)
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 88817a3376ef..6c393cd84925 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -2424,20 +2424,20 @@ static int arm_smmu_attach_dev(struct iommu_domain
*domain, struct device *dev)
"cannot attach to SMMU %s (upstream of %s)\n",
dev_name(smmu_domain->smmu->dev),
dev_name(smmu->dev));
- ret = -ENXIO;
+ ret = -EMEDIUMTYPE;
goto out_unlock;
} else if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1 &&
master->ssid_bits != smmu_domain->s1_cfg.s1cdmax) {
dev_err(dev,
"cannot attach to incompatible domain (%u SSID bits !=
%u)\n",
smmu_domain->s1_cfg.s1cdmax, master->ssid_bits);
- ret = -EINVAL;
+ ret = -EMEDIUMTYPE;
goto out_unlock;
} else if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1 &&
smmu_domain->stall_enabled != master->stall_enabled) {
dev_err(dev, "cannot attach to stall-%s domain\n",
smmu_domain->stall_enabled ? "enabled" : "disabled");
- ret = -EINVAL;
+ ret = -EMEDIUMTYPE;
goto out_unlock;
}
diff --git a/drivers/iommu/arm/arm-smmu/qcom_iommu.c
b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
index 4c077c38fbd6..a8b63b855ffb 100644
--- a/drivers/iommu/arm/arm-smmu/qcom_iommu.c
+++ b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
@@ -386,7 +386,7 @@ static int qcom_iommu_attach_dev(struct iommu_domain
*domain, struct device *dev
"attached to domain on IOMMU %s\n",
dev_name(qcom_domain->iommu->dev),
dev_name(qcom_iommu->dev));
- return -EINVAL;
+ return -EMEDIUMTYPE;
}
return 0;
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 44016594831d..0813b119d680 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -4323,7
[PATCH 0/5] Simplify vfio_iommu_type1 attach/detach routine
This is a preparatory series for IOMMUFD v2 patches. It enforces error code -EMEDIUMTYPE in iommu_attach_device() and iommu_attach_group() when an IOMMU domain and a device/group are incompatible. It also moves the domain->ops check into __iommu_attach_device(). These allow VFIO iommu code to simplify its group attachment routine, by avoiding the extra IOMMU domain allocations and attach/detach sequences of the old code. Worths mentioning the exact match for enforce_cache_coherency is removed with this series, since there's very less value in doing that since KVM won't be able to take advantage of it -- this just wastes domain memory. Instead, we rely on Intel IOMMU driver taking care of that internally. This is on github: https://github.com/nicolinc/iommufd/commits/vfio_iommu_attach Jason Gunthorpe (1): vfio/iommu_type1: Prefer to reuse domains vs match enforced cache coherency Nicolin Chen (4): iommu: Return -EMEDIUMTYPE for incompatible domain and device/group iommu: Ensure device has the same iommu_ops as the domain vfio/iommu_type1: Clean up update_dirty_scope in detach_group() vfio/iommu_type1: Simplify group attachment drivers/iommu/amd/iommu.c | 3 +- drivers/iommu/apple-dart.c | 5 +- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 7 +- drivers/iommu/arm/arm-smmu/arm-smmu.c | 1 + drivers/iommu/arm/arm-smmu/qcom_iommu.c | 3 +- drivers/iommu/exynos-iommu.c| 1 + drivers/iommu/fsl_pamu_domain.c | 1 + drivers/iommu/intel/iommu.c | 5 +- drivers/iommu/iommu.c | 26 ++ drivers/iommu/ipmmu-vmsa.c | 3 +- drivers/iommu/msm_iommu.c | 1 + drivers/iommu/mtk_iommu.c | 1 + drivers/iommu/mtk_iommu_v1.c| 1 + drivers/iommu/omap-iommu.c | 3 +- drivers/iommu/rockchip-iommu.c | 1 + drivers/iommu/s390-iommu.c | 1 + drivers/iommu/sprd-iommu.c | 1 + drivers/iommu/sun50i-iommu.c| 1 + drivers/iommu/tegra-gart.c | 1 + drivers/iommu/tegra-smmu.c | 1 + drivers/iommu/virtio-iommu.c| 3 +- drivers/vfio/vfio_iommu_type1.c | 315 ++-- include/linux/iommu.h | 2 + 23 files changed, 223 insertions(+), 164 deletions(-) -- 2.17.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 09/12] iommu/vt-d: Check device list of domain in domain free path
On 2022/6/2 14:29, Tian, Kevin wrote:
From: Baolu Lu
Sent: Wednesday, June 1, 2022 7:02 PM
On 2022/6/1 17:28, Tian, Kevin wrote:
From: Lu Baolu
Sent: Friday, May 27, 2022 2:30 PM
When the IOMMU domain is about to be freed, it should not be set on
any
device. Instead of silently dealing with some bug cases, it's better to
trigger a warning to report and fix any potential bugs at the first time.
static void domain_exit(struct dmar_domain *domain)
{
-
- /* Remove associated devices and clear attached or cached domains
*/
- domain_remove_dev_info(domain);
+ if (WARN_ON(!list_empty(&domain->devices)))
+ return;
warning is good but it doesn't mean the driver shouldn't deal with
that situation to make it safer e.g. blocking DMA from all attached
device...
I have ever thought the same thing. :-)
Blocking DMA from attached device should be done when setting blocking
domain to the device. It should not be part of freeing a domain.
yes but here we are talking about some bug scenario.
Here, the caller asks the driver to free the domain, but the driver
finds that something is wrong. Therefore, it warns and returns directly.
The domain will still be there in use until the next set_domain().
at least it'd look safer if we always try to unmap the entire domain i.e.:
static void domain_exit(struct dmar_domain *domain)
{
-
- /* Remove associated devices and clear attached or cached domains */
- domain_remove_dev_info(domain);
if (domain->pgd) {
LIST_HEAD(freelist);
domain_unmap(domain, 0, DOMAIN_MAX_PFN(domain->gaw), &freelist);
put_pages_list(&freelist);
}
+ if (WARN_ON(!list_empty(&domain->devices)))
+ return;
kfree(domain);
}
Fair enough. Removing all mappings is safer.
Best regards,
baolu
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 0/9] Add dynamic iommu backed bounce buffers
On Fri, Jun 3, 2022 at 11:53 PM Niklas Schnelle wrote: > > On Fri, 2022-05-27 at 10:25 +0900, David Stevens wrote: > > On Tue, May 24, 2022 at 9:27 PM Niklas Schnelle > > wrote: > > > On Fri, 2021-08-06 at 19:34 +0900, David Stevens wrote: > > > > From: David Stevens > > > > > > > > This patch series adds support for per-domain dynamic pools of iommu > > > > bounce buffers to the dma-iommu API. This allows iommu mappings to be > > > > reused while still maintaining strict iommu protection. > > > > > > > > This bounce buffer support is used to add a new config option that, when > > > > enabled, causes all non-direct streaming mappings below a configurable > > > > size to go through the bounce buffers. This serves as an optimization on > > > > systems where manipulating iommu mappings is very expensive. For > > > > example, virtio-iommu operations in a guest on a linux host require a > > > > vmexit, involvement the VMM, and a VFIO syscall. For relatively small > > > > DMA operations, memcpy can be significantly faster. > > > > > > > > As a performance comparison, on a device with an i5-10210U, I ran fio > > > > with a VFIO passthrough NVMe drive and virtio-iommu with '--direct=1 > > > > --rw=read --ioengine=libaio --iodepth=64' and block sizes 4k, 16k, 64k, > > > > and 128k. Test throughput increased by 2.8x, 4.7x, 3.6x, and 3.6x. Time > > > > spent in iommu_dma_unmap_(page|sg) per GB processed decreased by 97%, > > > > 94%, 90%, and 87%. Time spent in iommu_dma_map_(page|sg) decreased > > > > by >99%, as bounce buffers don't require syncing here in the read case. > > > > Running with multiple jobs doesn't serve as a useful performance > > > > comparison because virtio-iommu and vfio_iommu_type1 both have big > > > > locks that significantly limit mulithreaded DMA performance. > > > > > > > > These pooled bounce buffers are also used for subgranule mappings with > > > > untrusted devices, replacing the single use bounce buffers used > > > > currently. The biggest difference here is that the new implementation > > > > maps a whole sglist using a single bounce buffer. The new implementation > > > > does not support using bounce buffers for only some segments of the > > > > sglist, so it may require more copying. However, the current > > > > implementation requires per-segment iommu map/unmap operations for all > > > > untrusted sglist mappings (fully aligned sglists included). On a > > > > i5-10210U laptop with the internal NVMe drive made to appear untrusted, > > > > fio --direct=1 --rw=read --ioengine=libaio --iodepth=64 --bs=64k showed > > > > a statistically significant decrease in CPU load from 2.28% -> 2.17% > > > > with the new iommu bounce buffer optimization enabled. > > > > > > > > Each domain's buffer pool is split into multiple power-of-2 size > > > > classes. Each class allocates a fixed number of buffer slot metadata. A > > > > large iova range is allocated, and each slot is assigned an iova from > > > > the range. This allows the iova to be easily mapped back to the slot, > > > > and allows the critical section of most pool operations to be constant > > > > time. The one exception is finding a cached buffer to reuse. These are > > > > only separated according to R/W permissions - the use of other > > > > permissions such as IOMMU_PRIV may require a linear search through the > > > > cache. However, these other permissions are rare and likely exhibit high > > > > locality, so the should not be a bottleneck in practice. > > > > > > > > Since untrusted devices may require bounce buffers, each domain has a > > > > fallback rbtree to manage single use buffers. This may be necessary if a > > > > very large number of DMA operations are simultaneously in-flight, or for > > > > very large individual DMA operations. > > > > > > > > This patch set does not use swiotlb. There are two primary ways in which > > > > swiotlb isn't compatible with per-domain buffer pools. First, swiotlb > > > > allocates buffers to be compatible with a single device, whereas > > > > per-domain buffer pools don't handle that during buffer allocation as a > > > > single buffer may end up being used by multiple devices. Second, swiotlb > > > > allocation establishes the original to bounce buffer mapping, which > > > > again doesn't work if buffers can be reused. Effectively the only code > > > > that can be shared between the two use cases is allocating slots from > > > > the swiotlb's memory. However, given that we're going to be allocating > > > > memory for use with an iommu, allocating memory from a block of memory > > > > explicitly set aside to deal with a lack of iommu seems kind of > > > > contradictory. At best there might be a small performance improvement if > > > > wiotlb allocation is faster than regular page allocation, but buffer > > > > allocation isn't on the hot path anyway. > > > > > > > > Not using the swiotlb has the benefit that memory doesn't have to be > > > > preallocated. Instead, bounce buffers consume
Re: [PATCH 2/6] iommu/qcom: Write TCR before TTBRs to fix ASID access behavior
On 2022-05-31 16:55:59, Will Deacon wrote: > On Fri, May 27, 2022 at 11:28:57PM +0200, Konrad Dybcio wrote: > > From: AngeloGioacchino Del Regno > > > > As also stated in the arm-smmu driver, we must write the TCR before > > writing the TTBRs, since the TCR determines the access behavior of > > some fields. > > Where is this stated in the arm-smmu driver? > > > > > Signed-off-by: AngeloGioacchino Del Regno > > > > Signed-off-by: Marijn Suijten > > Signed-off-by: Konrad Dybcio > > --- > > drivers/iommu/arm/arm-smmu/qcom_iommu.c | 12 ++-- > > 1 file changed, 6 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/iommu/arm/arm-smmu/qcom_iommu.c > > b/drivers/iommu/arm/arm-smmu/qcom_iommu.c > > index 1728d4d7fe25..75f353866c40 100644 > > --- a/drivers/iommu/arm/arm-smmu/qcom_iommu.c > > +++ b/drivers/iommu/arm/arm-smmu/qcom_iommu.c > > @@ -273,18 +273,18 @@ static int qcom_iommu_init_domain(struct iommu_domain > > *domain, > > ctx->secure_init = true; > > } > > > > - /* TTBRs */ > > - iommu_writeq(ctx, ARM_SMMU_CB_TTBR0, > > - pgtbl_cfg.arm_lpae_s1_cfg.ttbr | > > - FIELD_PREP(ARM_SMMU_TTBRn_ASID, ctx->asid)); > > - iommu_writeq(ctx, ARM_SMMU_CB_TTBR1, 0); > > - > > /* TCR */ > > iommu_writel(ctx, ARM_SMMU_CB_TCR2, > > arm_smmu_lpae_tcr2(&pgtbl_cfg)); > > iommu_writel(ctx, ARM_SMMU_CB_TCR, > > arm_smmu_lpae_tcr(&pgtbl_cfg) | ARM_SMMU_TCR_EAE); > > > > + /* TTBRs */ > > + iommu_writeq(ctx, ARM_SMMU_CB_TTBR0, > > + pgtbl_cfg.arm_lpae_s1_cfg.ttbr | > > + FIELD_PREP(ARM_SMMU_TTBRn_ASID, ctx->asid)); > > + iommu_writeq(ctx, ARM_SMMU_CB_TTBR1, 0); > > I'd have thought that SCTLR.M would be clear here, so it shouldn't matter > what order we write these in. Having tested the series without this particular patch on 8976 (Sony Loire Suzu), it doesn't seem to matter indeed. I'll ask around if this "access behaviour" was observed on a different board/platform. - Marijn ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH V4 5/8] dt-bindings: Add xen,grant-dma IOMMU description for xen-grant DMA ops
On Thu, 02 Jun 2022 22:23:50 +0300, Oleksandr Tyshchenko wrote: > From: Oleksandr Tyshchenko > > The main purpose of this binding is to communicate Xen specific > information using generic IOMMU device tree bindings (which is > a good fit here) rather than introducing a custom property. > > Introduce Xen specific IOMMU for the virtualized device (e.g. virtio) > to be used by Xen grant DMA-mapping layer in the subsequent commit. > > The reference to Xen specific IOMMU node using "iommus" property > indicates that Xen grant mappings need to be enabled for the device, > and it specifies the ID of the domain where the corresponding backend > resides. The domid (domain ID) is used as an argument to the Xen grant > mapping APIs. > > This is needed for the option to restrict memory access using Xen grant > mappings to work which primary goal is to enable using virtio devices > in Xen guests. > > Signed-off-by: Oleksandr Tyshchenko > Reviewed-by: Stefano Stabellini > --- > Changes RFC -> V1: >- update commit subject/description and text in description >- move to devicetree/bindings/arm/ > > Changes V1 -> V2: >- update text in description >- change the maintainer of the binding >- fix validation issue >- reference xen,dev-domid.yaml schema from virtio/mmio.yaml > > Change V2 -> V3: >- Stefano already gave his Reviewed-by, I dropped it due to the changes > (significant) >- use generic IOMMU device tree bindings instead of custom property > "xen,dev-domid" >- change commit subject and description, was > "dt-bindings: Add xen,dev-domid property description for xen-grant DMA > ops" > > Changes V3 -> V4: >- add Stefano's R-b >- remove underscore in iommu node name >- remove consumer example virtio@3000 >- update text for two descriptions > --- > .../devicetree/bindings/iommu/xen,grant-dma.yaml | 39 > ++ > 1 file changed, 39 insertions(+) > create mode 100644 Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml > Reviewed-by: Rob Herring ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/3] dt-bindings: iommu: mediatek: add binding documentation for MT8365 SoC
On Mon, May 30, 2022 at 08:03:26PM +0200, Fabien Parent wrote: > Add IOMMU binding documentation for the MT8365 SoC. > > Signed-off-by: Fabien Parent > --- > .../bindings/iommu/mediatek,iommu.yaml| 2 + > include/dt-bindings/memory/mt8365-larb-port.h | 96 +++ > 2 files changed, 98 insertions(+) > create mode 100644 include/dt-bindings/memory/mt8365-larb-port.h > > diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml > b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml > index 97e8c471a5e8..5ba688365da5 100644 > --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml > +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml > @@ -77,6 +77,7 @@ properties: >- mediatek,mt8173-m4u # generation two >- mediatek,mt8183-m4u # generation two >- mediatek,mt8192-m4u # generation two > + - mediatek,mt8365-m4u # generation two > >- description: mt7623 generation one > items: > @@ -120,6 +121,7 @@ properties: >dt-binding/memory/mt8173-larb-port.h for mt8173, >dt-binding/memory/mt8183-larb-port.h for mt8183, >dt-binding/memory/mt8192-larb-port.h for mt8192. > + dt-binding/memory/mt8365-larb-port.h for mt8365. > >power-domains: > maxItems: 1 > diff --git a/include/dt-bindings/memory/mt8365-larb-port.h > b/include/dt-bindings/memory/mt8365-larb-port.h > new file mode 100644 > index ..e7d5637aa38e > --- /dev/null > +++ b/include/dt-bindings/memory/mt8365-larb-port.h > @@ -0,0 +1,96 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ Dual license please. Rob ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
