If caching mode is supported, the hardware will cache
none-present or erroneous translation entries. Hence,
software should explicitly invalidate the PASID cache
after a PASID table entry becomes present. We should
issue such invalidation with the PASID value that we
have changed. PASID 0 is not reserved for this case.
Cc: Jacob Pan
Cc: Kevin Tian
Cc: Sankaran Rajesh
Suggested-by: Ashok Raj
Signed-off-by: Liu Yi L
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-svm.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/iommu/intel-svm.c b/drivers/iommu/intel-svm.c
index 99bc9bd..b7b88b5 100644
--- a/drivers/iommu/intel-svm.c
+++ b/drivers/iommu/intel-svm.c
@@ -422,17 +422,13 @@ int intel_svm_bind_mm(struct device *dev, int *pasid, int
flags, struct svm_dev_
iommu->pasid_table[svm->pasid].val = pasid_entry_val;
wmb();
- /* In caching mode, we still have to flush with PASID 0 when
-* a PASID table entry becomes present. Not entirely clear
-* *why* that would be the case — surely we could just issue
-* a flush with the PASID value that we've changed? The PASID
-* is the index into the table, after all. It's not like domain
-* IDs in the case of the equivalent context-entry change in
-* caching mode. And for that matter it's not entirely clear why
-* a VMM would be in the business of caching the PASID table
-* anyway. Surely that can be left entirely to the guest? */
+
+ /*
+* Flush PASID cache when a PASID table entry becomes
+* present.
+*/
if (cap_caching_mode(iommu->cap))
- intel_flush_pasid_dev(svm, sdev, 0);
+ intel_flush_pasid_dev(svm, sdev, svm->pasid);
}
list_add_rcu(&sdev->list, &svm->devs);
--
2.7.4
