RE: [PATCH v2 2/3] iommu/sva: Stop using ioasid_set for SVA
From: Tian, Kevin
Date: Tue Feb 14 2023 - 22:24:27 EST
> From: Jacob Pan <jacob.jun.pan@xxxxxxxxxxxxxxx>
> Sent: Tuesday, February 14, 2023 2:44 PM
>
> From: Jason Gunthorpe <jgg@xxxxxxxxxx>
>
> Instead SVA drivers can use a simple global IDA to allocate PASIDs for
> each mm_struct.
>
> Future work would be to allow drivers using the SVA APIs to reserve global
> PASIDs from this IDA for their internal use, eg with the DMA API PASID
> support.
I think DMA API PASID will need new API around this IDA. SVA APIs should
be just for SVA.
> +void mm_pasid_drop(struct mm_struct *mm)
> {
> - return mmget_not_zero(mm);
> -}
> + pr_alert("%s %d", __func__, mm->pasid);
> + if (likely(!pasid_valid(mm->pasid)))
> + return;
>
> -/**
> - * iommu_sva_find() - Find mm associated to the given PASID
> - * @pasid: Process Address Space ID assigned to the mm
> - *
> - * On success a reference to the mm is taken, and must be released with
> mmput().
> - *
> - * Returns the mm corresponding to this PASID, or an error if not found.
> - */
> -struct mm_struct *iommu_sva_find(ioasid_t pasid)
> -{
> - return ioasid_find(&iommu_sva_pasid, pasid, __mmget_not_zero);
> + ida_free(&iommu_global_pasid_ida, mm->pasid);
> }
when moving this function following line is missed:
mm->pasid = INVALID_IOASID;
btw the current placement looks asymmetric. We now have
mm_pasid_init() and mm_pasid_set() in mm.h while mm_pasid_drop()
in iommu-sva.c.
Is it cleaner to introduce a iommu_sva_free_pasid() helper and then
call it from mm_pasid_drop() in mm.h?