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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux