Re: [RFC PATCH 1/5] iommu: Add APIs for IOMMU PASID management

[Lu Baolu]

Hi,

On 12/16/18 6:38 AM, Liu, Yi L wrote:
> > 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.

But drivers might call this during initialization when it doesn't has
any domain yet.

Best regards,
Lu Baolu