> From: Lu Baolu [mailto:baolu.lu@xxxxxxxxxxxxxxx] > Sent: Sunday, November 11, 2018 10:45 PM > Subject: [RFC PATCH 1/5] iommu: Add APIs for IOMMU PASID management > > This adds APIs for IOMMU drivers and device drivers to manage the PASIDs used for > DMA transfer and translation. It bases on I/O ASID allocator for PASID namespace > management and relies on vendor specific IOMMU drivers for paravirtual PASIDs. > > Below APIs are added: > > * iommu_pasid_init(pasid) > - Initialize a PASID consumer. The vendor specific IOMMU > drivers are able to set the PASID range imposed by IOMMU > hardware through a callback in iommu_ops. > > * iommu_pasid_exit(pasid) > - The PASID consumer stops consuming any PASID. > > * iommu_pasid_alloc(pasid, min, max, private, *ioasid) > - Allocate a PASID and associate a @private data with this > PASID. The PASID value is stored in @ioaisd if returning > success. > > * iommu_pasid_free(pasid, ioasid) > - Free a PASID to the pool so that it could be consumed by > others. > > This also adds below helpers to lookup or iterate PASID items associated with a > consumer. > > * iommu_pasid_for_each(pasid, func, data) > - Iterate PASID items of the consumer identified by @pasid, > and call @func() against each item. An error returned from > @func() will break the iteration. > > * iommu_pasid_find(pasid, ioasid) > - Retrieve the private data associated with @ioasid. > > Cc: Ashok Raj <ashok.raj@xxxxxxxxx> > Cc: Jacob Pan <jacob.jun.pan@xxxxxxxxxxxxxxx> > Cc: Kevin Tian <kevin.tian@xxxxxxxxx> > Cc: Jean-Philippe Brucker <jean-philippe.brucker@xxxxxxx> > Signed-off-by: Lu Baolu <baolu.lu@xxxxxxxxxxxxxxx> > --- > drivers/iommu/Kconfig | 1 + > drivers/iommu/iommu.c | 89 +++++++++++++++++++++++++++++++++++++++++++ > include/linux/iommu.h | 73 +++++++++++++++++++++++++++++++++++ > 3 files changed, 163 insertions(+) > > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index > d9a25715650e..39f2bb76c7b8 100644 > --- a/drivers/iommu/Kconfig > +++ b/drivers/iommu/Kconfig > @@ -1,6 +1,7 @@ > # IOMMU_API always gets selected by whoever wants it. > config IOMMU_API > bool > + select IOASID > > menuconfig IOMMU_SUPPORT > bool "IOMMU Hardware Support" > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index > 0b7c96d1425e..570b244897bb 100644 > --- a/drivers/iommu/iommu.c > +++ b/drivers/iommu/iommu.c > @@ -2082,3 +2082,92 @@ void iommu_detach_device_aux(struct iommu_domain > *domain, struct device *dev) > } > } > EXPORT_SYMBOL_GPL(iommu_detach_device_aux); > + > +/* > + * APIs for PASID used by IOMMU and the device drivers which depend > + * on IOMMU. > + */ > +struct iommu_pasid *iommu_pasid_init(struct bus_type *bus) { I'm thinking about if using struct iommu_domain here is better than struct bus_type. The major purpose is to pass iommu_ops in it and route into iommu-sublayer. iommu_domain may be better since some modules like vfio_iommu_type1 would use iommu_domain more than bus type. Thanks, Yi Liu
