> From: Jacob Pan <jacob.jun.pan@xxxxxxxxxxxxxxx> > Sent: Wednesday, June 1, 2022 4:44 AM > > Hi Jason, > > On Tue, 31 May 2022 16:05:50 -0300, Jason Gunthorpe <jgg@xxxxxxxxxx> > wrote: > > > On Tue, May 31, 2022 at 10:29:55AM -0700, Jacob Pan wrote: > > > > > The reason why I store PASID at IOMMU domain is for IOTLB flush within > > > the domain. Device driver is not aware of domain level IOTLB flush. We > > > also have iova_cookie for each domain which essentially is for > > > RIDPASID. > > > > You need to make the PASID stuff work generically. > > > > The domain needs to hold a list of all the places it needs to flush > > and that list needs to be maintained during attach/detach. > > > > A single PASID on the domain is obviously never going to work > > generically. > > > I agree, I did it this way really meant to be part of iommu_domain's > iommu_dma_cookie, not meant to be global. But for the lack of common > storage between identity domain and dma domain, I put it here as global. > > Then should we also extract RIDPASID to become part of the generic API? > i.e. set pasid, flush IOTLB etc. Right? RIDPASID is not in group's > pasid_array today. > RIDPASID is just an alias to RID in the PASID table (similar to pasid#0 on other platforms). it's reserved and not exposed outside the intel-iommu driver. So I don't think it should be managed via the generic iommu API. But probably you can generalize it with other pasids within intel-iommu driver if doing so can simplify the logic there.
