diff options
author | Lu Baolu <baolu.lu@linux.intel.com> | 2018-03-16 00:31:36 -0400 |
---|---|---|
committer | Joerg Roedel <jroedel@suse.de> | 2018-03-20 14:43:27 -0400 |
commit | 971401015d14dfbb483aa6385f8bddc1afad0c32 (patch) | |
tree | 4d22aeb82c9ffb239c9c3b61325fa50531e6d2b6 | |
parent | bbe4b3af9d9e3172fb9aa1f8dcdfaedcb381fc64 (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.c | 16 |
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 | ||