On Wed, Apr 10, 2024 at 10:08:44AM +0800, Lu Baolu wrote:
The struct intel_svm was used for keeping attached devices info for sva
domain. Since sva domain is a kind of iommu_domain, the struct
dmar_domain should centralize all info of a sva domain, including the
info of attached devices. Therefore, retire struct intel_svm to clean up
the code.
Besides, allocate sva domain in domain_alloc_sva() callback which allows
the memory management notifier lifetime to follow the lifetime of the
iommu_domain.
Co-developed-by: Tina Zhang <tina.zhang@xxxxxxxxx>
Signed-off-by: Tina Zhang <tina.zhang@xxxxxxxxx>
Signed-off-by: Lu Baolu <baolu.lu@xxxxxxxxxxxxxxx>
---
drivers/iommu/intel/iommu.h | 26 ++++------
drivers/iommu/intel/iommu.c | 9 +---
drivers/iommu/intel/svm.c | 94 +++++++++----------------------------
3 files changed, 32 insertions(+), 97 deletions(-)
Happy to see the pasid xarray in the driver go away.
@@ -4388,14 +4386,8 @@ static void intel_iommu_remove_dev_pasid(struct device *dev, ioasid_t pasid)
WARN_ON_ONCE(!dev_pasid);
spin_unlock_irqrestore(&dmar_domain->lock, flags);
- /*
- * The SVA implementation needs to handle its own stuffs like the mm
- * notification. Before consolidating that code into iommu core, let
- * the intel sva code handle it.
- */
if (domain->type == IOMMU_DOMAIN_SVA) {
cache_tag_unassign_domain(dmar_domain, FLPT_DEFAULT_DID, dev, pasid);
- intel_svm_remove_dev_pasid(domain);
} else {
did = domain_id_iommu(dmar_domain, iommu);
cache_tag_unassign_domain(dmar_domain, did, dev, pasid);
It seems very strange that SVA has a different DID scheme, why is
this? PASID and SVA should not be different at this layer.
@@ -663,7 +596,12 @@ void intel_svm_page_response(struct device *dev, struct iopf_fault *evt,
static void intel_svm_domain_free(struct iommu_domain *domain)
{
- kfree(to_dmar_domain(domain));
+ struct dmar_domain *dmar_domain = to_dmar_domain(domain);
+
+ if (dmar_domain->notifier.ops)
+ mmu_notifier_unregister(&dmar_domain->notifier, domain->mm);
This should really use mmu_notifier_put() and a delayed kfree, see my
part 2 ARM series for how that should look.
Otherwise I think it looks fine