On Thu Feb 06 20, Jerry Snitselaar wrote:
...
The above cases seem to be avoided by:
9235cb13d7d1 | 2020-01-24 | iommu/vt-d: Allow devices with RMRRs to use
identity domain (Lu Baolu)
which results in the watchdog device no longer taking a dma domain and
switching the group default.
Without that patch though when it gets into the iommu_need_mapping code for
0000:01:00.4 after
the following:
dmar_remove_one_dev_info(dev);
ret = iommu_request_dma_domain_for_dev(dev);
ret is 0 and dev->archdata.iommu is NULL. Even with 9235cb13d7d1
device_def_domain_type can return
return dma, but I'm not sure how likely it is for there to be an iommu group
like that again where
the group default ends up dma, a device gets removed and added to the identity
domain, and then
ends up in that code in iommu_need_mapping.
Hi Baolu,
Would something along these lines makes sense?
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 9dc37672bf89..40cc8f5a3ebb 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -3614,6 +3614,20 @@ static bool iommu_need_mapping(struct device *dev)
}
dmar_remove_one_dev_info(dev);
get_private_domain_for_dev(dev);
+ } else {
+ if (dev->archdata.iommu == NULL) {
+ struct iommu_domain *domain;
+ struct iommu_group *group;
+ struct dmar_domain *dmar_domain, *tmp;
+
+ group = iommu_group_get_for_dev(dev);
+ domain = iommu_group_default_domain(group);
+ dmar_domain = to_dmar_domain(domain);
+ tmp = set_domain_for_dev(dev, dmar_domain);
+ }
}
dev_info(dev, "32bit DMA uses non-identity mapping\n");
--
Obviously needs some checks added, but this was just an initial test I
was trying.
Regards,
Jerry
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
