From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lu Baolu Subject: Re: [RFC PATCH 1/5] iommu: Add APIs for IOMMU PASID management Date: Sun, 16 Dec 2018 09:20:38 +0800 Message-ID: <63ba6b78-ab31-4f54-002c-4c3baf818d3e@linux.intel.com> References: <20181112064501.2290-1-baolu.lu@linux.intel.com> <20181112064501.2290-2-baolu.lu@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: "Liu, Yi L" , Joerg Roedel , David Woodhouse , Alex Williamson , Kirti Wankhede Cc: "Tian, Kevin" , "Raj, Ashok" , "Bie, Tiwei" , Jean-Philippe Brucker , "Kumar, Sanjay K" , "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "Sun, Yi Y" , "Pan, Jacob jun" , "kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: iommu@lists.linux-foundation.org Hi, On 12/16/18 6:38 AM, Liu, Yi L wrote: >> From: Lu Baolu [mailto:baolu.lu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org] >> 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 >> Cc: Jacob Pan >> Cc: Kevin Tian >> Cc: Jean-Philippe Brucker >> Signed-off-by: Lu Baolu >> --- >> 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