Messages in this thread | | | Date | Mon, 24 May 2021 11:54:00 -0700 | From | Jacob Pan <> | Subject | Re: [PATCH 01/11] iommu/vt-d: Add pasid private data helpers |
| |
Hi Lu,
On Mon, 24 May 2021 10:16:18 +0800, Lu Baolu <baolu.lu@linux.intel.com> wrote:
> Hi Jacob, > > Thanks for reviewing my patch. > > On 5/22/21 5:25 AM, Jacob Pan wrote: > > Hi BaoLu, > > > > On Thu, 20 May 2021 11:15:21 +0800, Lu Baolu <baolu.lu@linux.intel.com> > > wrote: > > > >> We are about to use iommu_sva_alloc/free_pasid() helpers in iommu core. > >> That means the pasid life cycle will be managed by iommu core. Use a > >> local array to save the per pasid private data instead of attaching it > >> the real pasid. > >> > > I feel a little awkward to have a separate xarray for storing per IOASID > > data. Seems duplicated. > > Jason suggested in another thread that we can make ioasid_data public > > and embeded in struct intel_svm, then we can get rid of the private data > > pointer. ioasid_find will return the ioasid_data, then we can retrieve > > the private data with container_of. > > The problem that this patch wants to solve is that the > iommu_sva_alloc_pasid() will attach the mm pointer to the sva pasid. > > pasid = ioasid_alloc(&iommu_sva_pasid, min, max, mm); > > Assuming that each sva pasid can have only a single private data > pointer, the vendor iommu driver shouldn't set the private data again. > You are right. I got confused with vSVM, the guest will have the private data assigned after the bind.
> > > > roughly, > > > > struct intel_svm { > > ... > > struct ioasid_data; > > }; > > > > struct ioasid_data { > > ioasid_t id; > > refcount_t refs; > > struct mm_struct *mm; > > }; > > > > This can be a separate patch/effort if it make sense to you. > > Yes if we have a better solution. > Will be part of the IOASID core change.
Thanks, > Best regards, > baolu
Thanks,
Jacob
| |