[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <63ba6b78-ab31-4f54-002c-4c3baf818d3e@linux.intel.com>
Date: Sun, 16 Dec 2018 09:20:38 +0800
From: Lu Baolu <baolu.lu@...ux.intel.com>
To: "Liu, Yi L" <yi.l.liu@...el.com>, Joerg Roedel <joro@...tes.org>,
David Woodhouse <dwmw2@...radead.org>,
Alex Williamson <alex.williamson@...hat.com>,
Kirti Wankhede <kwankhede@...dia.com>
Cc: baolu.lu@...ux.intel.com, "Raj, Ashok" <ashok.raj@...el.com>,
"Kumar, Sanjay K" <sanjay.k.kumar@...el.com>,
"Pan, Jacob jun" <jacob.jun.pan@...el.com>,
"Tian, Kevin" <kevin.tian@...el.com>,
Jean-Philippe Brucker <jean-philippe.brucker@....com>,
"Sun, Yi Y" <yi.y.sun@...el.com>,
"peterx@...hat.com" <peterx@...hat.com>,
"Bie, Tiwei" <tiwei.bie@...el.com>,
"Zeng, Xin" <xin.zeng@...el.com>,
"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Jacob Pan <jacob.jun.pan@...ux.intel.com>
Subject: Re: [RFC PATCH 1/5] iommu: Add APIs for IOMMU PASID management
Hi,
On 12/16/18 6:38 AM, Liu, Yi L wrote:
>> From: Lu Baolu [mailto:baolu.lu@...ux.intel.com]
>> 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@...el.com>
>> Cc: Jacob Pan <jacob.jun.pan@...ux.intel.com>
>> Cc: Kevin Tian <kevin.tian@...el.com>
>> Cc: Jean-Philippe Brucker <jean-philippe.brucker@....com>
>> Signed-off-by: Lu Baolu <baolu.lu@...ux.intel.com>
>> ---
>> 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
Powered by blists - more mailing lists