iommu/vt-d: Use real PASID for flush in caching mode (97140101) · Commits · 戴 / test

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>

drivers/iommu/intel-svm.c

+6 −10

Original line number	Original line	Diff line number	Diff line
	@@ -423,17 +423,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;		iommu->pasid_table[svm->pasid].val = pasid_entry_val;

	wmb();		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		* Flush PASID cache when a PASID table entry becomes
	* a flush with the PASID value that we've changed? The PASID		* present.
	* 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? */
	if (cap_caching_mode(iommu->cap))		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);		list_add_rcu(&sdev->list, &svm->devs);

Admin message