| Message ID | 20230407180554.2784285-4-jacob.jun.pan@linux.intel.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Re-enable IDXD kernel workqueue under DMA API | expand |
On 4/8/23 2:05 AM, Jacob Pan wrote: > Devices that use Intel ENQCMD to submit work must use global PASIDs in > that the PASID are stored in a per CPU MSR. When such device need to > submit work for in-kernel DMA with PASID, it must allocate PASIDs from > the same global number space to avoid conflict. > > This patch moves global PASID allocation APIs from SVA to IOMMU APIs. > It is expected that device drivers will use the allocated PASIDs to attach > to appropriate IOMMU domains for use. > > Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com> > --- > v4: move dummy functions outside ifdef CONFIG_IOMMU_SVA (Baolu) > --- > drivers/iommu/iommu-sva.c | 10 ++++------ > drivers/iommu/iommu.c | 33 +++++++++++++++++++++++++++++++++ > include/linux/iommu.h | 11 +++++++++++ > 3 files changed, 48 insertions(+), 6 deletions(-) > > diff --git a/drivers/iommu/iommu-sva.c b/drivers/iommu/iommu-sva.c > index c434b95dc8eb..222544587582 100644 > --- a/drivers/iommu/iommu-sva.c > +++ b/drivers/iommu/iommu-sva.c > @@ -9,15 +9,13 @@ > #include "iommu-sva.h" > > static DEFINE_MUTEX(iommu_sva_lock); > -static DEFINE_IDA(iommu_global_pasid_ida); > > /* Allocate a PASID for the mm within range (inclusive) */ > static int iommu_sva_alloc_pasid(struct mm_struct *mm, ioasid_t min, ioasid_t max) > { > int ret = 0; > > - if (!pasid_valid(min) || !pasid_valid(max) || > - min == 0 || max < min) > + if (!pasid_valid(min) || !pasid_valid(max) || max < min) > return -EINVAL; > > mutex_lock(&iommu_sva_lock); > @@ -28,8 +26,8 @@ static int iommu_sva_alloc_pasid(struct mm_struct *mm, ioasid_t min, ioasid_t ma > goto out; > } > > - ret = ida_alloc_range(&iommu_global_pasid_ida, min, max, GFP_KERNEL); > - if (ret < min) > + ret = iommu_alloc_global_pasid(min, max); > + if (!pasid_valid(ret)) > goto out; > mm->pasid = ret; > ret = 0; > @@ -211,5 +209,5 @@ void mm_pasid_drop(struct mm_struct *mm) > if (likely(!pasid_valid(mm->pasid))) > return; > > - ida_free(&iommu_global_pasid_ida, mm->pasid); > + iommu_free_global_pasid(mm->pasid); > } > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c > index 10db680acaed..2a132ff7e3de 100644 > --- a/drivers/iommu/iommu.c > +++ b/drivers/iommu/iommu.c > @@ -38,6 +38,7 @@ > > static struct kset *iommu_group_kset; > static DEFINE_IDA(iommu_group_ida); > +static DEFINE_IDA(iommu_global_pasid_ida); > > static unsigned int iommu_def_domain_type __read_mostly; > static bool iommu_dma_strict __read_mostly = IS_ENABLED(CONFIG_IOMMU_DEFAULT_DMA_STRICT); > @@ -3450,3 +3451,35 @@ struct iommu_domain *iommu_sva_domain_alloc(struct device *dev, > > return domain; > } > + > +/** > + * @brief > + * Allocate a PASID from the global number space. > + * > + * @param min starting range, inclusive > + * @param max ending range, inclusive > + * @return The reserved PASID on success or IOMMU_PASID_INVALID on failure. > + */ > +ioasid_t iommu_alloc_global_pasid(ioasid_t min, ioasid_t max) > +{ > + int ret; > + > + if (!pasid_valid(min) || !pasid_valid(max) || max < min) > + return IOMMU_PASID_INVALID; > + > + ret = ida_alloc_range(&iommu_global_pasid_ida, min, max, GFP_KERNEL); > + if (ret < 0) > + return IOMMU_PASID_INVALID; > + > + return ret; > +} > +EXPORT_SYMBOL_GPL(iommu_alloc_global_pasid); > + > +void iommu_free_global_pasid(ioasid_t pasid) > +{ > + if (WARN_ON(!pasid_valid(pasid))) > + return; > + > + ida_free(&iommu_global_pasid_ida, pasid); > +} > +EXPORT_SYMBOL_GPL(iommu_free_global_pasid); > diff --git a/include/linux/iommu.h b/include/linux/iommu.h > index 54f535ff9868..c9720ddc81d2 100644 > --- a/include/linux/iommu.h > +++ b/include/linux/iommu.h > @@ -723,6 +723,8 @@ void iommu_detach_device_pasid(struct iommu_domain *domain, > struct iommu_domain * > iommu_get_domain_for_dev_pasid(struct device *dev, ioasid_t pasid, > unsigned int type); > +ioasid_t iommu_alloc_global_pasid(ioasid_t min, ioasid_t max); > +void iommu_free_global_pasid(ioasid_t pasid); > #else /* CONFIG_IOMMU_API */ > > struct iommu_ops {}; > @@ -1089,6 +1091,13 @@ iommu_get_domain_for_dev_pasid(struct device *dev, ioasid_t pasid, > { > return NULL; > } > + > +static inline ioasid_t iommu_alloc_global_pasid(ioasid_t min, ioasid_t max) > +{ > + return IOMMU_PASID_INVALID; > +} > + > +static inline void iommu_free_global_pasid(ioasid_t pasid) {} > #endif /* CONFIG_IOMMU_API */ > > /** > @@ -1187,6 +1196,7 @@ struct iommu_sva *iommu_sva_bind_device(struct device *dev, > struct mm_struct *mm); > void iommu_sva_unbind_device(struct iommu_sva *handle); > u32 iommu_sva_get_pasid(struct iommu_sva *handle); > + Nit: irrelevant blank line > #else > static inline struct iommu_sva * > iommu_sva_bind_device(struct device *dev, struct mm_struct *mm) > @@ -1202,6 +1212,7 @@ static inline u32 iommu_sva_get_pasid(struct iommu_sva *handle) > { > return IOMMU_PASID_INVALID; > } > + Ditto > static inline void mm_pasid_init(struct mm_struct *mm) {} > static inline void mm_pasid_drop(struct mm_struct *mm) {} > #endif /* CONFIG_IOMMU_SVA */ Other look good to me. Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Best regards, baolu
> From: Jacob Pan <jacob.jun.pan@linux.intel.com> > Sent: Saturday, April 8, 2023 2:06 AM > @@ -28,8 +26,8 @@ static int iommu_sva_alloc_pasid(struct mm_struct > *mm, ioasid_t min, ioasid_t ma > goto out; > } > > - ret = ida_alloc_range(&iommu_global_pasid_ida, min, max, > GFP_KERNEL); > - if (ret < min) > + ret = iommu_alloc_global_pasid(min, max); I wonder whether this can take a device pointer so dev->iommu->max_pasids is enforced inside the alloc function. and do we even need the min/max parameters? With special pasids reserved then what driver needs is just to get a free pasid from the global space within dev->iommu->max_pasids constraint... iommu_sva_alloc_pasid() can be reworked to avoid min/max by taking a device pointer too.
On 4/11/23 4:02 PM, Tian, Kevin wrote: >> From: Jacob Pan <jacob.jun.pan@linux.intel.com> >> Sent: Saturday, April 8, 2023 2:06 AM >> @@ -28,8 +26,8 @@ static int iommu_sva_alloc_pasid(struct mm_struct >> *mm, ioasid_t min, ioasid_t ma >> goto out; >> } >> >> - ret = ida_alloc_range(&iommu_global_pasid_ida, min, max, >> GFP_KERNEL); >> - if (ret < min) >> + ret = iommu_alloc_global_pasid(min, max); > > I wonder whether this can take a device pointer so dev->iommu->max_pasids > is enforced inside the alloc function. Agreed. Instead of using the open code, it looks better to have a helper like dev_iommu_max_pasids(). > > and do we even need the min/max parameters? With special pasids reserved > then what driver needs is just to get a free pasid from the global space within > dev->iommu->max_pasids constraint... > > iommu_sva_alloc_pasid() can be reworked to avoid min/max by taking a > device pointer too. Best regards, baolu
Hi Kevin, On Tue, 11 Apr 2023 08:02:55 +0000, "Tian, Kevin" <kevin.tian@intel.com> wrote: > > From: Jacob Pan <jacob.jun.pan@linux.intel.com> > > Sent: Saturday, April 8, 2023 2:06 AM > > @@ -28,8 +26,8 @@ static int iommu_sva_alloc_pasid(struct mm_struct > > *mm, ioasid_t min, ioasid_t ma > > goto out; > > } > > > > - ret = ida_alloc_range(&iommu_global_pasid_ida, min, max, > > GFP_KERNEL); > > - if (ret < min) > > + ret = iommu_alloc_global_pasid(min, max); > > I wonder whether this can take a device pointer so dev->iommu->max_pasids > is enforced inside the alloc function. > > and do we even need the min/max parameters? With special pasids reserved > then what driver needs is just to get a free pasid from the global space > within dev->iommu->max_pasids constraint... > > iommu_sva_alloc_pasid() can be reworked to avoid min/max by taking a > device pointer too. I think that will work too albeit a philosophical change. It probably should be called iommu_alloc_dev_global_pasid(dev). But I feel the current approach is more flexible in that device drivers can control the range if for some reason it does not want go max_pasid. Thanks, Jacob
Hi Baolu, On Wed, 12 Apr 2023 09:37:48 +0800, Baolu Lu <baolu.lu@linux.intel.com> wrote: > On 4/11/23 4:02 PM, Tian, Kevin wrote: > >> From: Jacob Pan <jacob.jun.pan@linux.intel.com> > >> Sent: Saturday, April 8, 2023 2:06 AM > >> @@ -28,8 +26,8 @@ static int iommu_sva_alloc_pasid(struct mm_struct > >> *mm, ioasid_t min, ioasid_t ma > >> goto out; > >> } > >> > >> - ret = ida_alloc_range(&iommu_global_pasid_ida, min, max, > >> GFP_KERNEL); > >> - if (ret < min) > >> + ret = iommu_alloc_global_pasid(min, max); > > > > I wonder whether this can take a device pointer so > > dev->iommu->max_pasids is enforced inside the alloc function. > > Agreed. Instead of using the open code, it looks better to have a helper > like dev_iommu_max_pasids(). yes, probably export dev_iommu_get_max_pasids(dev)? But if I understood Kevin correctly, he's also suggesting that the interface should be changed to iommu_alloc_global_pasid(dev), my concern is that how do we use this function to reserve RID_PASID which is not specific to a device? > > > > > and do we even need the min/max parameters? With special pasids reserved > > then what driver needs is just to get a free pasid from the global > > space within dev->iommu->max_pasids constraint... > > > > iommu_sva_alloc_pasid() can be reworked to avoid min/max by taking a > > device pointer too. > > Best regards, > baolu Thanks, Jacob
On 4/18/23 12:46 AM, Jacob Pan wrote: > On Wed, 12 Apr 2023 09:37:48 +0800, Baolu Lu<baolu.lu@linux.intel.com> > wrote: > >> On 4/11/23 4:02 PM, Tian, Kevin wrote: >>>> From: Jacob Pan<jacob.jun.pan@linux.intel.com> >>>> Sent: Saturday, April 8, 2023 2:06 AM >>>> @@ -28,8 +26,8 @@ static int iommu_sva_alloc_pasid(struct mm_struct >>>> *mm, ioasid_t min, ioasid_t ma >>>> goto out; >>>> } >>>> >>>> - ret = ida_alloc_range(&iommu_global_pasid_ida, min, max, >>>> GFP_KERNEL); >>>> - if (ret < min) >>>> + ret = iommu_alloc_global_pasid(min, max); >>> I wonder whether this can take a device pointer so >>> dev->iommu->max_pasids is enforced inside the alloc function. >> Agreed. Instead of using the open code, it looks better to have a helper >> like dev_iommu_max_pasids(). > yes, probably export dev_iommu_get_max_pasids(dev)? > > But if I understood Kevin correctly, he's also suggesting that the > interface should be changed to iommu_alloc_global_pasid(dev), my concern is > that how do we use this function to reserve RID_PASID which is not specific > to a device? Probably we can introduce a counterpart dev->iommu->min_pasids, so that there's no need to reserve the RID_PASID. At present, we can set it to 1 in the core as ARM/AMD/Intel all treat PASID 0 as a special pasid. In the future, if VT-d supports using arbitrary number as RID_PASID for any specific device, we can call iommu_alloc_global_pasid() for that device. The device drivers don't know and don't need to know the range of viable PASIDs, so the @min, @max parameters seem to be unreasonable. Best regards, baolu
Hi Baolu, On Tue, 18 Apr 2023 10:06:12 +0800, Baolu Lu <baolu.lu@linux.intel.com> wrote: > On 4/18/23 12:46 AM, Jacob Pan wrote: > > On Wed, 12 Apr 2023 09:37:48 +0800, Baolu Lu<baolu.lu@linux.intel.com> > > wrote: > > > >> On 4/11/23 4:02 PM, Tian, Kevin wrote: > >>>> From: Jacob Pan<jacob.jun.pan@linux.intel.com> > >>>> Sent: Saturday, April 8, 2023 2:06 AM > >>>> @@ -28,8 +26,8 @@ static int iommu_sva_alloc_pasid(struct mm_struct > >>>> *mm, ioasid_t min, ioasid_t ma > >>>> goto out; > >>>> } > >>>> > >>>> - ret = ida_alloc_range(&iommu_global_pasid_ida, min, max, > >>>> GFP_KERNEL); > >>>> - if (ret < min) > >>>> + ret = iommu_alloc_global_pasid(min, max); > >>> I wonder whether this can take a device pointer so > >>> dev->iommu->max_pasids is enforced inside the alloc function. > >> Agreed. Instead of using the open code, it looks better to have a > >> helper like dev_iommu_max_pasids(). > > yes, probably export dev_iommu_get_max_pasids(dev)? > > > > But if I understood Kevin correctly, he's also suggesting that the > > interface should be changed to iommu_alloc_global_pasid(dev), my > > concern is that how do we use this function to reserve RID_PASID which > > is not specific to a device? > > Probably we can introduce a counterpart dev->iommu->min_pasids, so that > there's no need to reserve the RID_PASID. At present, we can set it to 1 > in the core as ARM/AMD/Intel all treat PASID 0 as a special pasid. > > In the future, if VT-d supports using arbitrary number as RID_PASID for > any specific device, we can call iommu_alloc_global_pasid() for that > device. > > The device drivers don't know and don't need to know the range of viable > PASIDs, so the @min, @max parameters seem to be unreasonable. Sure, that is reasonable. Another question is whether global PASID allocation is always for a single device, if not I prefer to keep the current iommu_alloc_global_pasid() and add a wrapper iommu_alloc_global_pasid_dev(dev) to extract the @min, @max. OK? Thanks, Jacob
On 4/19/23 7:04 AM, Jacob Pan wrote: > On Tue, 18 Apr 2023 10:06:12 +0800, Baolu Lu<baolu.lu@linux.intel.com> > wrote: > >> On 4/18/23 12:46 AM, Jacob Pan wrote: >>> On Wed, 12 Apr 2023 09:37:48 +0800, Baolu Lu<baolu.lu@linux.intel.com> >>> wrote: >>> >>>> On 4/11/23 4:02 PM, Tian, Kevin wrote: >>>>>> From: Jacob Pan<jacob.jun.pan@linux.intel.com> >>>>>> Sent: Saturday, April 8, 2023 2:06 AM >>>>>> @@ -28,8 +26,8 @@ static int iommu_sva_alloc_pasid(struct mm_struct >>>>>> *mm, ioasid_t min, ioasid_t ma >>>>>> goto out; >>>>>> } >>>>>> >>>>>> - ret = ida_alloc_range(&iommu_global_pasid_ida, min, max, >>>>>> GFP_KERNEL); >>>>>> - if (ret < min) >>>>>> + ret = iommu_alloc_global_pasid(min, max); >>>>> I wonder whether this can take a device pointer so >>>>> dev->iommu->max_pasids is enforced inside the alloc function. >>>> Agreed. Instead of using the open code, it looks better to have a >>>> helper like dev_iommu_max_pasids(). >>> yes, probably export dev_iommu_get_max_pasids(dev)? >>> >>> But if I understood Kevin correctly, he's also suggesting that the >>> interface should be changed to iommu_alloc_global_pasid(dev), my >>> concern is that how do we use this function to reserve RID_PASID which >>> is not specific to a device? >> Probably we can introduce a counterpart dev->iommu->min_pasids, so that >> there's no need to reserve the RID_PASID. At present, we can set it to 1 >> in the core as ARM/AMD/Intel all treat PASID 0 as a special pasid. >> >> In the future, if VT-d supports using arbitrary number as RID_PASID for >> any specific device, we can call iommu_alloc_global_pasid() for that >> device. >> >> The device drivers don't know and don't need to know the range of viable >> PASIDs, so the @min, @max parameters seem to be unreasonable. > Sure, that is reasonable. Another question is whether global PASID > allocation is always for a single device, if not I prefer to keep the > current iommu_alloc_global_pasid() and add a wrapper > iommu_alloc_global_pasid_dev(dev) to extract the @min, @max. OK? No problem from the code perspective. But we only need one API. We can now add the kAPI that we really need. In this series, the idxd driver wants to allocate a global PASID for its kernel dma with pasid purpose. So, iommu_alloc_global_pasid_dev() seems to be sufficient. If, in the future, we will have a need to provide global pasid allocation other than device drivers, we can easily add the variants. Best regards, baolu
Hi Baolu, On Wed, 19 Apr 2023 10:40:46 +0800, Baolu Lu <baolu.lu@linux.intel.com> wrote: > On 4/19/23 7:04 AM, Jacob Pan wrote: > > On Tue, 18 Apr 2023 10:06:12 +0800, Baolu Lu<baolu.lu@linux.intel.com> > > wrote: > > > >> On 4/18/23 12:46 AM, Jacob Pan wrote: > >>> On Wed, 12 Apr 2023 09:37:48 +0800, Baolu Lu<baolu.lu@linux.intel.com> > >>> wrote: > >>> > >>>> On 4/11/23 4:02 PM, Tian, Kevin wrote: > >>>>>> From: Jacob Pan<jacob.jun.pan@linux.intel.com> > >>>>>> Sent: Saturday, April 8, 2023 2:06 AM > >>>>>> @@ -28,8 +26,8 @@ static int iommu_sva_alloc_pasid(struct mm_struct > >>>>>> *mm, ioasid_t min, ioasid_t ma > >>>>>> goto out; > >>>>>> } > >>>>>> > >>>>>> - ret = ida_alloc_range(&iommu_global_pasid_ida, min, max, > >>>>>> GFP_KERNEL); > >>>>>> - if (ret < min) > >>>>>> + ret = iommu_alloc_global_pasid(min, max); > >>>>> I wonder whether this can take a device pointer so > >>>>> dev->iommu->max_pasids is enforced inside the alloc function. > >>>> Agreed. Instead of using the open code, it looks better to have a > >>>> helper like dev_iommu_max_pasids(). > >>> yes, probably export dev_iommu_get_max_pasids(dev)? > >>> > >>> But if I understood Kevin correctly, he's also suggesting that the > >>> interface should be changed to iommu_alloc_global_pasid(dev), my > >>> concern is that how do we use this function to reserve RID_PASID which > >>> is not specific to a device? > >> Probably we can introduce a counterpart dev->iommu->min_pasids, so that > >> there's no need to reserve the RID_PASID. At present, we can set it to > >> 1 in the core as ARM/AMD/Intel all treat PASID 0 as a special pasid. > >> > >> In the future, if VT-d supports using arbitrary number as RID_PASID for > >> any specific device, we can call iommu_alloc_global_pasid() for that > >> device. > >> > >> The device drivers don't know and don't need to know the range of > >> viable PASIDs, so the @min, @max parameters seem to be unreasonable. > > Sure, that is reasonable. Another question is whether global PASID > > allocation is always for a single device, if not I prefer to keep the > > current iommu_alloc_global_pasid() and add a wrapper > > iommu_alloc_global_pasid_dev(dev) to extract the @min, @max. OK? > > No problem from the code perspective. But we only need one API. > > We can now add the kAPI that we really need. In this series, the idxd > driver wants to allocate a global PASID for its kernel dma with pasid > purpose. So, iommu_alloc_global_pasid_dev() seems to be sufficient. > > If, in the future, we will have a need to provide global pasid > allocation other than device drivers, we can easily add the variants. > sounds good, I will only add iommu_alloc_global_pasid_dev(dev). let the core code set @min, @max for devices. Thanks, Jacob
diff --git a/drivers/iommu/iommu-sva.c b/drivers/iommu/iommu-sva.c index c434b95dc8eb..222544587582 100644 --- a/drivers/iommu/iommu-sva.c +++ b/drivers/iommu/iommu-sva.c @@ -9,15 +9,13 @@ #include "iommu-sva.h" static DEFINE_MUTEX(iommu_sva_lock); -static DEFINE_IDA(iommu_global_pasid_ida); /* Allocate a PASID for the mm within range (inclusive) */ static int iommu_sva_alloc_pasid(struct mm_struct *mm, ioasid_t min, ioasid_t max) { int ret = 0; - if (!pasid_valid(min) || !pasid_valid(max) || - min == 0 || max < min) + if (!pasid_valid(min) || !pasid_valid(max) || max < min) return -EINVAL; mutex_lock(&iommu_sva_lock); @@ -28,8 +26,8 @@ static int iommu_sva_alloc_pasid(struct mm_struct *mm, ioasid_t min, ioasid_t ma goto out; } - ret = ida_alloc_range(&iommu_global_pasid_ida, min, max, GFP_KERNEL); - if (ret < min) + ret = iommu_alloc_global_pasid(min, max); + if (!pasid_valid(ret)) goto out; mm->pasid = ret; ret = 0; @@ -211,5 +209,5 @@ void mm_pasid_drop(struct mm_struct *mm) if (likely(!pasid_valid(mm->pasid))) return; - ida_free(&iommu_global_pasid_ida, mm->pasid); + iommu_free_global_pasid(mm->pasid); } diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index 10db680acaed..2a132ff7e3de 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -38,6 +38,7 @@ static struct kset *iommu_group_kset; static DEFINE_IDA(iommu_group_ida); +static DEFINE_IDA(iommu_global_pasid_ida); static unsigned int iommu_def_domain_type __read_mostly; static bool iommu_dma_strict __read_mostly = IS_ENABLED(CONFIG_IOMMU_DEFAULT_DMA_STRICT); @@ -3450,3 +3451,35 @@ struct iommu_domain *iommu_sva_domain_alloc(struct device *dev, return domain; } + +/** + * @brief + * Allocate a PASID from the global number space. + * + * @param min starting range, inclusive + * @param max ending range, inclusive + * @return The reserved PASID on success or IOMMU_PASID_INVALID on failure. + */ +ioasid_t iommu_alloc_global_pasid(ioasid_t min, ioasid_t max) +{ + int ret; + + if (!pasid_valid(min) || !pasid_valid(max) || max < min) + return IOMMU_PASID_INVALID; + + ret = ida_alloc_range(&iommu_global_pasid_ida, min, max, GFP_KERNEL); + if (ret < 0) + return IOMMU_PASID_INVALID; + + return ret; +} +EXPORT_SYMBOL_GPL(iommu_alloc_global_pasid); + +void iommu_free_global_pasid(ioasid_t pasid) +{ + if (WARN_ON(!pasid_valid(pasid))) + return; + + ida_free(&iommu_global_pasid_ida, pasid); +} +EXPORT_SYMBOL_GPL(iommu_free_global_pasid); diff --git a/include/linux/iommu.h b/include/linux/iommu.h index 54f535ff9868..c9720ddc81d2 100644 --- a/include/linux/iommu.h +++ b/include/linux/iommu.h @@ -723,6 +723,8 @@ void iommu_detach_device_pasid(struct iommu_domain *domain, struct iommu_domain * iommu_get_domain_for_dev_pasid(struct device *dev, ioasid_t pasid, unsigned int type); +ioasid_t iommu_alloc_global_pasid(ioasid_t min, ioasid_t max); +void iommu_free_global_pasid(ioasid_t pasid); #else /* CONFIG_IOMMU_API */ struct iommu_ops {}; @@ -1089,6 +1091,13 @@ iommu_get_domain_for_dev_pasid(struct device *dev, ioasid_t pasid, { return NULL; } + +static inline ioasid_t iommu_alloc_global_pasid(ioasid_t min, ioasid_t max) +{ + return IOMMU_PASID_INVALID; +} + +static inline void iommu_free_global_pasid(ioasid_t pasid) {} #endif /* CONFIG_IOMMU_API */ /** @@ -1187,6 +1196,7 @@ struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct *mm); void iommu_sva_unbind_device(struct iommu_sva *handle); u32 iommu_sva_get_pasid(struct iommu_sva *handle); + #else static inline struct iommu_sva * iommu_sva_bind_device(struct device *dev, struct mm_struct *mm) @@ -1202,6 +1212,7 @@ static inline u32 iommu_sva_get_pasid(struct iommu_sva *handle) { return IOMMU_PASID_INVALID; } + static inline void mm_pasid_init(struct mm_struct *mm) {} static inline void mm_pasid_drop(struct mm_struct *mm) {} #endif /* CONFIG_IOMMU_SVA */
Devices that use Intel ENQCMD to submit work must use global PASIDs in that the PASID are stored in a per CPU MSR. When such device need to submit work for in-kernel DMA with PASID, it must allocate PASIDs from the same global number space to avoid conflict. This patch moves global PASID allocation APIs from SVA to IOMMU APIs. It is expected that device drivers will use the allocated PASIDs to attach to appropriate IOMMU domains for use. Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com> --- v4: move dummy functions outside ifdef CONFIG_IOMMU_SVA (Baolu) --- drivers/iommu/iommu-sva.c | 10 ++++------ drivers/iommu/iommu.c | 33 +++++++++++++++++++++++++++++++++ include/linux/iommu.h | 11 +++++++++++ 3 files changed, 48 insertions(+), 6 deletions(-)