aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorLu Baolu <baolu.lu@linux.intel.com>2018-03-16 00:31:36 -0400
committerJoerg Roedel <jroedel@suse.de>2018-03-20 14:43:27 -0400
commit971401015d14dfbb483aa6385f8bddc1afad0c32 (patch)
tree4d22aeb82c9ffb239c9c3b61325fa50531e6d2b6
parentbbe4b3af9d9e3172fb9aa1f8dcdfaedcb381fc64 (diff)
iommu/vt-d: Use real PASID for flush in caching mode
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 <jacob.jun.pan@linux.intel.com> Cc: Kevin Tian <kevin.tian@intel.com> Cc: Sankaran Rajesh <rajesh.sankaran@intel.com> Suggested-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Liu Yi L <yi.l.liu@intel.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
-rw-r--r--drivers/iommu/intel-svm.c16
1 files changed, 6 insertions, 10 deletions
diff --git a/drivers/iommu/intel-svm.c b/drivers/iommu/intel-svm.c
index 3d4b9245542d..43737d37fdf2 100644
--- a/drivers/iommu/intel-svm.c
+++ b/drivers/iommu/intel-svm.c
@@ -423,17 +423,13 @@ int intel_svm_bind_mm(struct device *dev, int *pasid, int flags, struct svm_dev_
423 iommu->pasid_table[svm->pasid].val = pasid_entry_val; 423 iommu->pasid_table[svm->pasid].val = pasid_entry_val;
424 424
425 wmb(); 425 wmb();
426 /* In caching mode, we still have to flush with PASID 0 when 426
427 * a PASID table entry becomes present. Not entirely clear 427 /*
428 * *why* that would be the case — surely we could just issue 428 * Flush PASID cache when a PASID table entry becomes
429 * a flush with the PASID value that we've changed? The PASID 429 * present.
430 * is the index into the table, after all. It's not like domain 430 */
431 * IDs in the case of the equivalent context-entry change in
432 * caching mode. And for that matter it's not entirely clear why
433 * a VMM would be in the business of caching the PASID table
434 * anyway. Surely that can be left entirely to the guest? */
435 if (cap_caching_mode(iommu->cap)) 431 if (cap_caching_mode(iommu->cap))
436 intel_flush_pasid_dev(svm, sdev, 0); 432 intel_flush_pasid_dev(svm, sdev, svm->pasid);
437 } 433 }
438 list_add_rcu(&sdev->list, &svm->devs); 434 list_add_rcu(&sdev->list, &svm->devs);
439 435