* [PATCH v2] iommu: Allow device driver to use its own PASID space for SVA
@ 2026-05-20 15:07 Joonwon Kang
2026-05-21 7:39 ` Baolu Lu
2026-05-25 8:10 ` Tian, Kevin
0 siblings, 2 replies; 12+ messages in thread
From: Joonwon Kang @ 2026-05-20 15:07 UTC (permalink / raw)
To: jgg, will, robin.murphy, joro, jpb
Cc: Alexander.Grest, amhetre, baolu.lu, easwar.hariharan,
jacob.jun.pan, kees, kevin.tian, nicolinc, praan, smostafa, tglx,
mingo, bp, dave.hansen, x86, hpa, peterz, sohil.mehta, kas,
alexander.shishkin, ryasuoka, xin, linux-kernel, iommu,
linux-arm-kernel, joonwonkang
For SVA, the IOMMU core always allocates PASID from the global PASID
space. The use of this global PASID space comes from the limitation of
the ENQCMD instruction in Intel CPUs that it fetches its PASID operand
from IA32_PASID, which is per-process; when a process wants to
communicate with multiple devices with the ENQCMD instruction, it cannot
change its PASID for each device without the kernel's intervention. Also
note that ARM introduced a similar instruction, which is ST64BV0.
Due to this nature, SVA with ARM SMMU v3 has been found not working in
our environment when other modules/devices compete for PASID. The
environment looks as follows:
- The device is not a PCIe device.
- The device is to use SVA.
- The supported SSID/PASID space is very small for the device; only 1 to
3 SSIDs are supported.
With this setup, when other modules have allocated all the PASIDs that
our device is expected to use from the global PASID space via APIs like
iommu_alloc_global_pasid() or iommu_sva_bind_device(), SVA binding to
our device fails due to the lack of available PASIDs.
This commit resolves the issue by allowing device driver to maintain its
own PASID space and assign a PASID from that for the process-device bond
via a new API called `iommu_sva_bind_device_pasid(dev, mm, pasid)`. Doing
that, however, will disallow the process to execute the ENQCMD-like
instructions at EL0. It is because the process cannot change its PASID in
IA32_PASID(or ACCDATA_EL1 on ARM) for each device without the kernel's
intervention. For this reason, calling `iommu_sva_bind_device()` and then
`iommu_sva_bind_device_pasid()` for the same process will not be allowed
and vice versa.
Currently, there is a limitation that a process simultaneously doing SVA
with multiple devices with different PASIDs is not supported. So, calling
`iommu_sva_bind_device_pasid()` multiple times for the same process with
different devices will not be allowed for now while that for
`iommu_sva_bind_device()` will be.
Another limitation is that a process cannot do `iommu_sva_bind_device()`
if it has ever done `iommu_sva_bind_device_pasid()` even though it has
been unbound after use.
Suggested-by: Jason Gunthorpe <jgg@ziepe•ca>
Suggested-by: Kevin Tian <kevin.tian@intel•com>
Signed-off-by: Joonwon Kang <joonwonkang@google•com>
---
v2: Reuse iommu_mm->pasid after SVA bound by iommu_sva_bind_device_pasid()
is unbound.
v1: Initial version.
arch/x86/kernel/traps.c | 9 +--
drivers/iommu/iommu-sva.c | 151 +++++++++++++++++++++++++++++---------
include/linux/iommu.h | 14 +++-
3 files changed, 134 insertions(+), 40 deletions(-)
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 0ca3912ecb7f..0131c8e5fb10 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -857,13 +857,12 @@ static bool try_fixup_enqcmd_gp(void)
return false;
/*
- * If the mm has not been allocated a
- * PASID, the #GP can not be fixed up.
+ * If the mm has not been allocated a PASID or ENQCMD has been
+ * disallowed, the #GP can not be fixed up.
*/
- if (!mm_valid_pasid(current->mm))
- return false;
-
pasid = mm_get_enqcmd_pasid(current->mm);
+ if (pasid == IOMMU_PASID_INVALID)
+ return false;
/*
* Did this thread already have its PASID activated?
diff --git a/drivers/iommu/iommu-sva.c b/drivers/iommu/iommu-sva.c
index bc7c7232a43e..a83333651ad0 100644
--- a/drivers/iommu/iommu-sva.c
+++ b/drivers/iommu/iommu-sva.c
@@ -10,6 +10,9 @@
#include "iommu-priv.h"
+/* Whether pasid is to be allocated from the global PASID space */
+#define IOMMU_PASID_GLOBAL_ANY IOMMU_NO_PASID
+
static DEFINE_MUTEX(iommu_sva_lock);
static bool iommu_sva_present;
static LIST_HEAD(iommu_sva_mms);
@@ -17,10 +20,11 @@ static struct iommu_domain *iommu_sva_domain_alloc(struct device *dev,
struct mm_struct *mm);
/* Allocate a PASID for the mm within range (inclusive) */
-static struct iommu_mm_data *iommu_alloc_mm_data(struct mm_struct *mm, struct device *dev)
+static struct iommu_mm_data *iommu_alloc_mm_data(struct mm_struct *mm,
+ struct device *dev,
+ ioasid_t pasid)
{
struct iommu_mm_data *iommu_mm;
- ioasid_t pasid;
lockdep_assert_held(&iommu_sva_lock);
@@ -30,8 +34,27 @@ static struct iommu_mm_data *iommu_alloc_mm_data(struct mm_struct *mm, struct de
iommu_mm = mm->iommu_mm;
/* Is a PASID already associated with this mm? */
if (iommu_mm) {
+ if ((pasid == IOMMU_PASID_GLOBAL_ANY && !iommu_mm->pasid_global) ||
+ (pasid != IOMMU_PASID_GLOBAL_ANY && iommu_mm->pasid_global))
+ return ERR_PTR(-EBUSY);
+
+ if (!iommu_mm->pasid_global) {
+ if (list_empty(&iommu_mm->sva_domains))
+ iommu_mm->pasid = pasid;
+
+ if (pasid != iommu_mm->pasid) {
+ /*
+ * Currently, a process simultaneously doing
+ * SVA with multiple devices with different
+ * PASIDs is not supported.
+ */
+ return ERR_PTR(-ENOSPC);
+ }
+ }
+
if (iommu_mm->pasid >= dev->iommu->max_pasids)
return ERR_PTR(-EOVERFLOW);
+
return iommu_mm;
}
@@ -39,37 +62,30 @@ static struct iommu_mm_data *iommu_alloc_mm_data(struct mm_struct *mm, struct de
if (!iommu_mm)
return ERR_PTR(-ENOMEM);
- pasid = iommu_alloc_global_pasid(dev);
- if (pasid == IOMMU_PASID_INVALID) {
- kfree(iommu_mm);
- return ERR_PTR(-ENOSPC);
+ if (pasid == IOMMU_PASID_GLOBAL_ANY) {
+ pasid = iommu_alloc_global_pasid(dev);
+ if (pasid == IOMMU_PASID_INVALID) {
+ kfree(iommu_mm);
+ return ERR_PTR(-ENOSPC);
+ }
+ iommu_mm->pasid_global = true;
+ } else {
+ if (pasid >= dev->iommu->max_pasids) {
+ kfree(iommu_mm);
+ return ERR_PTR(-EOVERFLOW);
+ }
+ iommu_mm->pasid_global = false;
}
iommu_mm->pasid = pasid;
iommu_mm->mm = mm;
INIT_LIST_HEAD(&iommu_mm->sva_domains);
- /*
- * Make sure the write to mm->iommu_mm is not reordered in front of
- * initialization to iommu_mm fields. If it does, readers may see a
- * valid iommu_mm with uninitialized values.
- */
- smp_store_release(&mm->iommu_mm, iommu_mm);
+
return iommu_mm;
}
-/**
- * iommu_sva_bind_device() - Bind a process address space to a device
- * @dev: the device
- * @mm: the mm to bind, caller must hold a reference to mm_users
- *
- * Create a bond between device and address space, allowing the device to
- * access the mm using the PASID returned by iommu_sva_get_pasid(). If a
- * bond already exists between @device and @mm, an additional internal
- * reference is taken. Caller must call iommu_sva_unbind_device()
- * to release each reference.
- *
- * On error, returns an ERR_PTR value.
- */
-struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct *mm)
+static struct iommu_sva *iommu_sva_bind_device_internal(struct device *dev,
+ struct mm_struct *mm,
+ ioasid_t pasid)
{
struct iommu_group *group = dev->iommu_group;
struct iommu_attach_handle *attach_handle;
@@ -84,7 +100,7 @@ struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct *mm
mutex_lock(&iommu_sva_lock);
/* Allocate mm->pasid if necessary. */
- iommu_mm = iommu_alloc_mm_data(mm, dev);
+ iommu_mm = iommu_alloc_mm_data(mm, dev, pasid);
if (IS_ERR(iommu_mm)) {
ret = PTR_ERR(iommu_mm);
goto out_unlock;
@@ -96,7 +112,7 @@ struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct *mm
handle = container_of(attach_handle, struct iommu_sva, handle);
if (attach_handle->domain->mm != mm) {
ret = -EBUSY;
- goto out_unlock;
+ goto out_free_iommu_mm;
}
refcount_inc(&handle->users);
mutex_unlock(&iommu_sva_lock);
@@ -105,17 +121,17 @@ struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct *mm
if (PTR_ERR(attach_handle) != -ENOENT) {
ret = PTR_ERR(attach_handle);
- goto out_unlock;
+ goto out_free_iommu_mm;
}
handle = kzalloc_obj(*handle);
if (!handle) {
ret = -ENOMEM;
- goto out_unlock;
+ goto out_free_iommu_mm;
}
/* Search for an existing domain. */
- list_for_each_entry(domain, &mm->iommu_mm->sva_domains, next) {
+ list_for_each_entry(domain, &iommu_mm->sva_domains, next) {
ret = iommu_attach_device_pasid(domain, dev, iommu_mm->pasid,
&handle->handle);
if (!ret) {
@@ -143,6 +159,15 @@ struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct *mm
list_add(&iommu_mm->mm_list_elm, &iommu_sva_mms);
}
list_add(&domain->next, &iommu_mm->sva_domains);
+ if (!mm->iommu_mm) {
+ /*
+ * Make sure the write to mm->iommu_mm is not reordered in
+ * front of initialization to iommu_mm fields. If it does,
+ * readers may see a valid iommu_mm with uninitialized values.
+ */
+ smp_store_release(&mm->iommu_mm, iommu_mm);
+ }
+
out:
refcount_set(&handle->users, 1);
mutex_unlock(&iommu_sva_lock);
@@ -153,12 +178,66 @@ struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct *mm
iommu_domain_free(domain);
out_free_handle:
kfree(handle);
+out_free_iommu_mm:
+ if (!mm->iommu_mm) {
+ if (iommu_mm->pasid_global)
+ iommu_free_global_pasid(iommu_mm->pasid);
+ kfree(iommu_mm);
+ }
out_unlock:
mutex_unlock(&iommu_sva_lock);
return ERR_PTR(ret);
}
+
+/**
+ * iommu_sva_bind_device() - Bind a process address space to a device
+ * @dev: the device
+ * @mm: the mm to bind, caller must hold a reference to mm_users
+ *
+ * Create a bond between device and address space, allowing the device to
+ * access the mm using the PASID returned by iommu_sva_get_pasid(). If a
+ * bond already exists between @device and @mm, an additional internal
+ * reference is taken. Caller must call iommu_sva_unbind_device()
+ * to release each reference.
+ *
+ * On error, returns an ERR_PTR value.
+ */
+struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct *mm)
+{
+ return iommu_sva_bind_device_internal(dev, mm, IOMMU_PASID_GLOBAL_ANY);
+}
EXPORT_SYMBOL_GPL(iommu_sva_bind_device);
+/**
+ * iommu_sva_bind_device_pasid() - Bind a process address space to a device
+ * with a designated pasid
+ * @dev: the device
+ * @mm: the mm to bind, caller must hold a reference to mm_users
+ * @pasid: the pasid to assign to the bond
+ *
+ * Create a bond between device and address space, allowing the device to
+ * access the mm using the PASID returned by iommu_sva_get_pasid(). If a
+ * bond already exists between @device and @mm, an additional internal
+ * reference is taken. Caller must call iommu_sva_unbind_device()
+ * to release each reference.
+ *
+ * It is the caller's responsibility to maintain the PASID space for @pasid.
+ * After the bond is created, the process for @mm will not be able to execute
+ * ENQCMD or similar instructions at EL0. To allow those instructions at EL0,
+ * iommu_sva_bind_device() must be used instead.
+ *
+ * On error, returns an ERR_PTR value.
+ */
+struct iommu_sva *iommu_sva_bind_device_pasid(struct device *dev,
+ struct mm_struct *mm,
+ ioasid_t pasid)
+{
+ if (pasid == IOMMU_PASID_GLOBAL_ANY)
+ return ERR_PTR(-EINVAL);
+ return iommu_sva_bind_device_internal(dev, mm, pasid);
+}
+EXPORT_SYMBOL_GPL(iommu_sva_bind_device_pasid);
+
/**
* iommu_sva_unbind_device() - Remove a bond created with iommu_sva_bind_device
* @handle: the handle returned by iommu_sva_bind_device()
@@ -198,9 +277,12 @@ EXPORT_SYMBOL_GPL(iommu_sva_unbind_device);
u32 iommu_sva_get_pasid(struct iommu_sva *handle)
{
- struct iommu_domain *domain = handle->handle.domain;
+ struct iommu_mm_data *iommu_mm = handle->handle.domain->mm->iommu_mm;
+
+ if (!iommu_mm)
+ return IOMMU_PASID_INVALID;
- return mm_get_enqcmd_pasid(domain->mm);
+ return iommu_mm->pasid;
}
EXPORT_SYMBOL_GPL(iommu_sva_get_pasid);
@@ -211,7 +293,8 @@ void mm_pasid_drop(struct mm_struct *mm)
if (!iommu_mm)
return;
- iommu_free_global_pasid(iommu_mm->pasid);
+ if (iommu_mm->pasid_global)
+ iommu_free_global_pasid(iommu_mm->pasid);
kfree(iommu_mm);
}
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index e587d4ac4d33..5b6116e7152d 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -1140,6 +1140,7 @@ struct iommu_sva {
struct iommu_mm_data {
u32 pasid;
+ bool pasid_global;
struct mm_struct *mm;
struct list_head sva_domains;
struct list_head mm_list_elm;
@@ -1626,7 +1627,7 @@ static inline u32 mm_get_enqcmd_pasid(struct mm_struct *mm)
{
struct iommu_mm_data *iommu_mm = READ_ONCE(mm->iommu_mm);
- if (!iommu_mm)
+ if (!iommu_mm || !iommu_mm->pasid_global)
return IOMMU_PASID_INVALID;
return iommu_mm->pasid;
}
@@ -1634,6 +1635,9 @@ static inline u32 mm_get_enqcmd_pasid(struct mm_struct *mm)
void mm_pasid_drop(struct mm_struct *mm);
struct iommu_sva *iommu_sva_bind_device(struct device *dev,
struct mm_struct *mm);
+struct iommu_sva *iommu_sva_bind_device_pasid(struct device *dev,
+ struct mm_struct *mm,
+ ioasid_t pasid);
void iommu_sva_unbind_device(struct iommu_sva *handle);
u32 iommu_sva_get_pasid(struct iommu_sva *handle);
void iommu_sva_invalidate_kva_range(unsigned long start, unsigned long end);
@@ -1644,6 +1648,14 @@ iommu_sva_bind_device(struct device *dev, struct mm_struct *mm)
return ERR_PTR(-ENODEV);
}
+static inline struct iommu_sva *
+iommu_sva_bind_device_pasid(struct device *dev,
+ struct mm_struct *mm,
+ ioasid_t pasid)
+{
+ return ERR_PTR(-ENODEV);
+}
+
static inline void iommu_sva_unbind_device(struct iommu_sva *handle)
{
}
--
2.54.0.631.ge1b05301d1-goog
^ permalink raw reply related [flat|nested] 12+ messages in thread* Re: [PATCH v2] iommu: Allow device driver to use its own PASID space for SVA
2026-05-20 15:07 [PATCH v2] iommu: Allow device driver to use its own PASID space for SVA Joonwon Kang
@ 2026-05-21 7:39 ` Baolu Lu
2026-05-21 8:25 ` Joonwon Kang
2026-05-25 8:10 ` Tian, Kevin
1 sibling, 1 reply; 12+ messages in thread
From: Baolu Lu @ 2026-05-21 7:39 UTC (permalink / raw)
To: Joonwon Kang, jgg, will, robin.murphy, joro, jpb
Cc: Alexander.Grest, amhetre, easwar.hariharan, jacob.jun.pan, kees,
kevin.tian, nicolinc, praan, smostafa, tglx, mingo, bp,
dave.hansen, x86, hpa, peterz, sohil.mehta, kas,
alexander.shishkin, ryasuoka, xin, linux-kernel, iommu,
linux-arm-kernel
On 5/20/26 23:07, Joonwon Kang wrote:
> For SVA, the IOMMU core always allocates PASID from the global PASID
> space. The use of this global PASID space comes from the limitation of
> the ENQCMD instruction in Intel CPUs that it fetches its PASID operand
> from IA32_PASID, which is per-process; when a process wants to
> communicate with multiple devices with the ENQCMD instruction, it cannot
> change its PASID for each device without the kernel's intervention. Also
> note that ARM introduced a similar instruction, which is ST64BV0.
>
> Due to this nature, SVA with ARM SMMU v3 has been found not working in
> our environment when other modules/devices compete for PASID. The
> environment looks as follows:
>
> - The device is not a PCIe device.
> - The device is to use SVA.
> - The supported SSID/PASID space is very small for the device; only 1 to
> 3 SSIDs are supported.
>
> With this setup, when other modules have allocated all the PASIDs that
> our device is expected to use from the global PASID space via APIs like
> iommu_alloc_global_pasid() or iommu_sva_bind_device(), SVA binding to
> our device fails due to the lack of available PASIDs.
>
> This commit resolves the issue by allowing device driver to maintain its
> own PASID space and assign a PASID from that for the process-device bond
> via a new API called `iommu_sva_bind_device_pasid(dev, mm, pasid)`. Doing
> that, however, will disallow the process to execute the ENQCMD-like
> instructions at EL0. It is because the process cannot change its PASID in
> IA32_PASID(or ACCDATA_EL1 on ARM) for each device without the kernel's
> intervention. For this reason, calling `iommu_sva_bind_device()` and then
> `iommu_sva_bind_device_pasid()` for the same process will not be allowed
> and vice versa.
>
> Currently, there is a limitation that a process simultaneously doing SVA
> with multiple devices with different PASIDs is not supported. So, calling
> `iommu_sva_bind_device_pasid()` multiple times for the same process with
> different devices will not be allowed for now while that for
> `iommu_sva_bind_device()` will be.
>
> Another limitation is that a process cannot do `iommu_sva_bind_device()`
> if it has ever done `iommu_sva_bind_device_pasid()` even though it has
> been unbound after use.
>
> Suggested-by: Jason Gunthorpe<jgg@ziepe•ca>
> Suggested-by: Kevin Tian<kevin.tian@intel•com>
> Signed-off-by: Joonwon Kang<joonwonkang@google•com>
> ---
> v2: Reuse iommu_mm->pasid after SVA bound by iommu_sva_bind_device_pasid()
> is unbound.
> v1: Initial version.
>
> arch/x86/kernel/traps.c | 9 +--
> drivers/iommu/iommu-sva.c | 151 +++++++++++++++++++++++++++++---------
> include/linux/iommu.h | 14 +++-
> 3 files changed, 134 insertions(+), 40 deletions(-)
>
> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> index 0ca3912ecb7f..0131c8e5fb10 100644
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -857,13 +857,12 @@ static bool try_fixup_enqcmd_gp(void)
> return false;
>
> /*
> - * If the mm has not been allocated a
> - * PASID, the #GP can not be fixed up.
> + * If the mm has not been allocated a PASID or ENQCMD has been
> + * disallowed, the #GP can not be fixed up.
> */
> - if (!mm_valid_pasid(current->mm))
> - return false;
> -
> pasid = mm_get_enqcmd_pasid(current->mm);
> + if (pasid == IOMMU_PASID_INVALID)
> + return false;
>
> /*
> * Did this thread already have its PASID activated?
> diff --git a/drivers/iommu/iommu-sva.c b/drivers/iommu/iommu-sva.c
> index bc7c7232a43e..a83333651ad0 100644
> --- a/drivers/iommu/iommu-sva.c
> +++ b/drivers/iommu/iommu-sva.c
> @@ -10,6 +10,9 @@
>
> #include "iommu-priv.h"
>
> +/* Whether pasid is to be allocated from the global PASID space */
> +#define IOMMU_PASID_GLOBAL_ANY IOMMU_NO_PASID
> +
> static DEFINE_MUTEX(iommu_sva_lock);
> static bool iommu_sva_present;
> static LIST_HEAD(iommu_sva_mms);
> @@ -17,10 +20,11 @@ static struct iommu_domain *iommu_sva_domain_alloc(struct device *dev,
> struct mm_struct *mm);
>
> /* Allocate a PASID for the mm within range (inclusive) */
> -static struct iommu_mm_data *iommu_alloc_mm_data(struct mm_struct *mm, struct device *dev)
> +static struct iommu_mm_data *iommu_alloc_mm_data(struct mm_struct *mm,
> + struct device *dev,
> + ioasid_t pasid)
> {
> struct iommu_mm_data *iommu_mm;
> - ioasid_t pasid;
>
> lockdep_assert_held(&iommu_sva_lock);
>
> @@ -30,8 +34,27 @@ static struct iommu_mm_data *iommu_alloc_mm_data(struct mm_struct *mm, struct de
> iommu_mm = mm->iommu_mm;
> /* Is a PASID already associated with this mm? */
> if (iommu_mm) {
> + if ((pasid == IOMMU_PASID_GLOBAL_ANY && !iommu_mm->pasid_global) ||
> + (pasid != IOMMU_PASID_GLOBAL_ANY && iommu_mm->pasid_global))
> + return ERR_PTR(-EBUSY);
> +
> + if (!iommu_mm->pasid_global) {
> + if (list_empty(&iommu_mm->sva_domains))
> + iommu_mm->pasid = pasid;
> +
> + if (pasid != iommu_mm->pasid) {
> + /*
> + * Currently, a process simultaneously doing
> + * SVA with multiple devices with different
> + * PASIDs is not supported.
> + */
I am a bit confused by the change in this helper and the comments above.
Currently, when an mm is bound to a device, it uses a PASID allocated
from the global pool. That implies that all devices access the
application's address space with the same PASID. Now we want to extend
this by allowing the device driver to manage the PASID for SVA, which
should mean different devices might use different PASIDs to access the
application's address space. But this does not seem to match the logic
in this helper.
Perhaps I overlooked something?
> + return ERR_PTR(-ENOSPC);
> + }
> + }
> +
> if (iommu_mm->pasid >= dev->iommu->max_pasids)
> return ERR_PTR(-EOVERFLOW);
> +
> return iommu_mm;
> }
Thanks,
baolu
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH v2] iommu: Allow device driver to use its own PASID space for SVA
2026-05-21 7:39 ` Baolu Lu
@ 2026-05-21 8:25 ` Joonwon Kang
0 siblings, 0 replies; 12+ messages in thread
From: Joonwon Kang @ 2026-05-21 8:25 UTC (permalink / raw)
To: baolu.lu
Cc: Alexander.Grest, alexander.shishkin, amhetre, bp, dave.hansen,
easwar.hariharan, hpa, iommu, jacob.jun.pan, jgg, joonwonkang,
joro, jpb, kas, kees, kevin.tian, linux-arm-kernel, linux-kernel,
mingo, nicolinc, peterz, praan, robin.murphy, ryasuoka, smostafa,
sohil.mehta, tglx, will, x86, xin
Hi Baolu, thanks for your review.
> On 5/20/26 23:07, Joonwon Kang wrote:
> > For SVA, the IOMMU core always allocates PASID from the global PASID
> > space. The use of this global PASID space comes from the limitation of
> > the ENQCMD instruction in Intel CPUs that it fetches its PASID operand
> > from IA32_PASID, which is per-process; when a process wants to
> > communicate with multiple devices with the ENQCMD instruction, it cannot
> > change its PASID for each device without the kernel's intervention. Also
> > note that ARM introduced a similar instruction, which is ST64BV0.
> >
> > Due to this nature, SVA with ARM SMMU v3 has been found not working in
> > our environment when other modules/devices compete for PASID. The
> > environment looks as follows:
> >
> > - The device is not a PCIe device.
> > - The device is to use SVA.
> > - The supported SSID/PASID space is very small for the device; only 1 to
> > 3 SSIDs are supported.
> >
> > With this setup, when other modules have allocated all the PASIDs that
> > our device is expected to use from the global PASID space via APIs like
> > iommu_alloc_global_pasid() or iommu_sva_bind_device(), SVA binding to
> > our device fails due to the lack of available PASIDs.
> >
> > This commit resolves the issue by allowing device driver to maintain its
> > own PASID space and assign a PASID from that for the process-device bond
> > via a new API called `iommu_sva_bind_device_pasid(dev, mm, pasid)`. Doing
> > that, however, will disallow the process to execute the ENQCMD-like
> > instructions at EL0. It is because the process cannot change its PASID in
> > IA32_PASID(or ACCDATA_EL1 on ARM) for each device without the kernel's
> > intervention. For this reason, calling `iommu_sva_bind_device()` and then
> > `iommu_sva_bind_device_pasid()` for the same process will not be allowed
> > and vice versa.
> >
> > Currently, there is a limitation that a process simultaneously doing SVA
> > with multiple devices with different PASIDs is not supported. So, calling
> > `iommu_sva_bind_device_pasid()` multiple times for the same process with
> > different devices will not be allowed for now while that for
> > `iommu_sva_bind_device()` will be.
> >
> > Another limitation is that a process cannot do `iommu_sva_bind_device()`
> > if it has ever done `iommu_sva_bind_device_pasid()` even though it has
> > been unbound after use.
> >
> > Suggested-by: Jason Gunthorpe<jgg@ziepe•ca>
> > Suggested-by: Kevin Tian<kevin.tian@intel•com>
> > Signed-off-by: Joonwon Kang<joonwonkang@google•com>
> > ---
> > v2: Reuse iommu_mm->pasid after SVA bound by iommu_sva_bind_device_pasid()
> > is unbound.
> > v1: Initial version.
> >
> > arch/x86/kernel/traps.c | 9 +--
> > drivers/iommu/iommu-sva.c | 151 +++++++++++++++++++++++++++++---------
> > include/linux/iommu.h | 14 +++-
> > 3 files changed, 134 insertions(+), 40 deletions(-)
> >
> > diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> > index 0ca3912ecb7f..0131c8e5fb10 100644
> > --- a/arch/x86/kernel/traps.c
> > +++ b/arch/x86/kernel/traps.c
> > @@ -857,13 +857,12 @@ static bool try_fixup_enqcmd_gp(void)
> > return false;
> >
> > /*
> > - * If the mm has not been allocated a
> > - * PASID, the #GP can not be fixed up.
> > + * If the mm has not been allocated a PASID or ENQCMD has been
> > + * disallowed, the #GP can not be fixed up.
> > */
> > - if (!mm_valid_pasid(current->mm))
> > - return false;
> > -
> > pasid = mm_get_enqcmd_pasid(current->mm);
> > + if (pasid == IOMMU_PASID_INVALID)
> > + return false;
> >
> > /*
> > * Did this thread already have its PASID activated?
> > diff --git a/drivers/iommu/iommu-sva.c b/drivers/iommu/iommu-sva.c
> > index bc7c7232a43e..a83333651ad0 100644
> > --- a/drivers/iommu/iommu-sva.c
> > +++ b/drivers/iommu/iommu-sva.c
> > @@ -10,6 +10,9 @@
> >
> > #include "iommu-priv.h"
> >
> > +/* Whether pasid is to be allocated from the global PASID space */
> > +#define IOMMU_PASID_GLOBAL_ANY IOMMU_NO_PASID
> > +
> > static DEFINE_MUTEX(iommu_sva_lock);
> > static bool iommu_sva_present;
> > static LIST_HEAD(iommu_sva_mms);
> > @@ -17,10 +20,11 @@ static struct iommu_domain *iommu_sva_domain_alloc(struct device *dev,
> > struct mm_struct *mm);
> >
> > /* Allocate a PASID for the mm within range (inclusive) */
> > -static struct iommu_mm_data *iommu_alloc_mm_data(struct mm_struct *mm, struct device *dev)
> > +static struct iommu_mm_data *iommu_alloc_mm_data(struct mm_struct *mm,
> > + struct device *dev,
> > + ioasid_t pasid)
> > {
> > struct iommu_mm_data *iommu_mm;
> > - ioasid_t pasid;
> >
> > lockdep_assert_held(&iommu_sva_lock);
> >
> > @@ -30,8 +34,27 @@ static struct iommu_mm_data *iommu_alloc_mm_data(struct mm_struct *mm, struct de
> > iommu_mm = mm->iommu_mm;
> > /* Is a PASID already associated with this mm? */
> > if (iommu_mm) {
> > + if ((pasid == IOMMU_PASID_GLOBAL_ANY && !iommu_mm->pasid_global) ||
> > + (pasid != IOMMU_PASID_GLOBAL_ANY && iommu_mm->pasid_global))
> > + return ERR_PTR(-EBUSY);
> > +
> > + if (!iommu_mm->pasid_global) {
> > + if (list_empty(&iommu_mm->sva_domains))
> > + iommu_mm->pasid = pasid;
> > +
> > + if (pasid != iommu_mm->pasid) {
> > + /*
> > + * Currently, a process simultaneously doing
> > + * SVA with multiple devices with different
> > + * PASIDs is not supported.
> > + */
>
> I am a bit confused by the change in this helper and the comments above.
>
> Currently, when an mm is bound to a device, it uses a PASID allocated
> from the global pool. That implies that all devices access the
> application's address space with the same PASID. Now we want to extend
> this by allowing the device driver to manage the PASID for SVA, which
> should mean different devices might use different PASIDs to access the
> application's address space. But this does not seem to match the logic
> in this helper.
>
> Perhaps I overlooked something?
>
I think your understanding is correct. In the long run, the limitations in the
comment and also in the commit message should be removed. I left the work to a
later patch as I am focusing on removing the main blocker first, which is that
a process is blocked by another irrelevant process for doing SVA as described
in the commit message. Currently, SVA for a process with different PASIDs will
only be allowed one after another, not simultaneously, and the current users of
`iommu_sva_bind_device()` should not be affected by this patch.
So, this patch should be enough to fix our current main problem. Can we leave
it to a later patch? or do you think we should remove the limitations now
although there is no requirement yet?
Thanks,
Joonwon Kang
> > + return ERR_PTR(-ENOSPC);
> > + }
> > + }
> > +
> > if (iommu_mm->pasid >= dev->iommu->max_pasids)
> > return ERR_PTR(-EOVERFLOW);
> > +
> > return iommu_mm;
> > }
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [PATCH v2] iommu: Allow device driver to use its own PASID space for SVA
2026-05-20 15:07 [PATCH v2] iommu: Allow device driver to use its own PASID space for SVA Joonwon Kang
2026-05-21 7:39 ` Baolu Lu
@ 2026-05-25 8:10 ` Tian, Kevin
2026-05-25 15:29 ` Joonwon Kang
1 sibling, 1 reply; 12+ messages in thread
From: Tian, Kevin @ 2026-05-25 8:10 UTC (permalink / raw)
To: Joonwon Kang, jgg@ziepe•ca, will@kernel•org, robin.murphy@arm•com,
joro@8bytes•org, jpb@kernel•org
Cc: Alexander.Grest@microsoft•com, amhetre@nvidia•com,
baolu.lu@linux•intel.com, easwar.hariharan@linux•microsoft.com,
jacob.jun.pan@linux•intel.com, kees@kernel•org,
nicolinc@nvidia•com, praan@google•com, smostafa@google•com,
tglx@kernel•org, mingo@redhat•com, bp@alien8•de,
dave.hansen@linux•intel.com, x86@kernel•org, hpa@zytor•com,
peterz@infradead•org, Mehta, Sohil, kas@kernel•org,
alexander.shishkin@linux•intel.com, ryasuoka@redhat•com,
xin@zytor•com, linux-kernel@vger•kernel.org,
iommu@lists•linux.dev, linux-arm-kernel@lists•infradead.org
> From: Joonwon Kang <joonwonkang@google•com>
> Sent: Wednesday, May 20, 2026 11:08 PM
>
[...]
>
> This commit resolves the issue by allowing device driver to maintain its
> own PASID space and assign a PASID from that for the process-device bond
> via a new API called `iommu_sva_bind_device_pasid(dev, mm, pasid)`. Doing
> that, however, will disallow the process to execute the ENQCMD-like
> instructions at EL0. It is because the process cannot change its PASID in
> IA32_PASID(or ACCDATA_EL1 on ARM) for each device without the kernel's
> intervention. For this reason, calling `iommu_sva_bind_device()` and then
> `iommu_sva_bind_device_pasid()` for the same process will not be allowed
> and vice versa.
>
> Currently, there is a limitation that a process simultaneously doing SVA
> with multiple devices with different PASIDs is not supported. So, calling
> `iommu_sva_bind_device_pasid()` multiple times for the same process with
> different devices will not be allowed for now while that for
> `iommu_sva_bind_device()` will be.
>
> Another limitation is that a process cannot do `iommu_sva_bind_device()`
> if it has ever done `iommu_sva_bind_device_pasid()` even though it has
> been unbound after use.
Why not making it clean in one step instead of leaving many unsupported
cases which are likely required soon in this "1" to "many" transition?
for each mm:
- one global pasid for ENQCMD or ST64BV0
- an array of device local pasids tracked in [struct device *, pasid] tuple.
upon gp fault or equivalent, fetch the global pasid.
upon device-specific bind, match [dev, pasid].
>
> Suggested-by: Jason Gunthorpe <jgg@ziepe•ca>
> Suggested-by: Kevin Tian <kevin.tian@intel•com>
> Signed-off-by: Joonwon Kang <joonwonkang@google•com>
> ---
> v2: Reuse iommu_mm->pasid after SVA bound by
> iommu_sva_bind_device_pasid()
> is unbound.
No idea what it talks about.
btw a new kAPI always needs accompanied users to review together.
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [PATCH v2] iommu: Allow device driver to use its own PASID space for SVA
2026-05-25 8:10 ` Tian, Kevin
@ 2026-05-25 15:29 ` Joonwon Kang
2026-05-25 16:47 ` Jason Gunthorpe
0 siblings, 1 reply; 12+ messages in thread
From: Joonwon Kang @ 2026-05-25 15:29 UTC (permalink / raw)
To: kevin.tian
Cc: Alexander.Grest, alexander.shishkin, amhetre, baolu.lu, bp,
dave.hansen, easwar.hariharan, hpa, iommu, jacob.jun.pan, jgg,
joonwonkang, joro, jpb, kas, kees, linux-arm-kernel, linux-kernel,
mingo, nicolinc, peterz, praan, robin.murphy, ryasuoka, smostafa,
sohil.mehta, tglx, will, x86, xin
Hi Kevin, thanks for your review.
> > This commit resolves the issue by allowing device driver to maintain its
> > own PASID space and assign a PASID from that for the process-device bond
> > via a new API called `iommu_sva_bind_device_pasid(dev, mm, pasid)`. Doing
> > that, however, will disallow the process to execute the ENQCMD-like
> > instructions at EL0. It is because the process cannot change its PASID in
> > IA32_PASID(or ACCDATA_EL1 on ARM) for each device without the kernel's
> > intervention. For this reason, calling `iommu_sva_bind_device()` and then
> > `iommu_sva_bind_device_pasid()` for the same process will not be allowed
> > and vice versa.
> >
> > Currently, there is a limitation that a process simultaneously doing SVA
> > with multiple devices with different PASIDs is not supported. So, calling
> > `iommu_sva_bind_device_pasid()` multiple times for the same process with
> > different devices will not be allowed for now while that for
> > `iommu_sva_bind_device()` will be.
> >
> > Another limitation is that a process cannot do `iommu_sva_bind_device()`
> > if it has ever done `iommu_sva_bind_device_pasid()` even though it has
> > been unbound after use.
>
> Why not making it clean in one step instead of leaving many unsupported
> cases which are likely required soon in this "1" to "many" transition?
>
Since I did not know much about the IOMMU team's future plans on the IOMMU
core structure, I narrowed down the scope just enough to resolve our
specific problem and avoided introducing big change. But now that I have
two queries to support the 1-to-many relationships in this patchset, not
in a later one, I think it is fair enough to start working on it now. I
will try it and lift the limitations.
> for each mm:
> - one global pasid for ENQCMD or ST64BV0
> - an array of device local pasids tracked in [struct device *, pasid] tuple.
>
> upon gp fault or equivalent, fetch the global pasid.
>
> upon device-specific bind, match [dev, pasid].
>
> >
> > Suggested-by: Jason Gunthorpe <jgg@ziepe•ca>
> > Suggested-by: Kevin Tian <kevin.tian@intel•com>
> > Signed-off-by: Joonwon Kang <joonwonkang@google•com>
> > ---
> > v2: Reuse iommu_mm->pasid after SVA bound by
> > iommu_sva_bind_device_pasid()
> > is unbound.
>
> No idea what it talks about.
>
There was a bug in v1 that the second call for `iommu_sva_bind_device_pasid()`
failed after the first call with a different PASID was released. Will
rephrase it in a clearer language in v3.
> btw a new kAPI always needs accompanied users to review together.
Currently, the only known expected user of the new kAPI is our team. Since
I test if the patch resolves our problem before sending it, I believe it
should be good enough. Do you mean more than our team by "accompanied
users"?
Thanks,
Joonwon Kang
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2] iommu: Allow device driver to use its own PASID space for SVA
2026-05-25 15:29 ` Joonwon Kang
@ 2026-05-25 16:47 ` Jason Gunthorpe
2026-05-26 6:58 ` Joonwon Kang
0 siblings, 1 reply; 12+ messages in thread
From: Jason Gunthorpe @ 2026-05-25 16:47 UTC (permalink / raw)
To: Joonwon Kang
Cc: kevin.tian, Alexander.Grest, alexander.shishkin, amhetre,
baolu.lu, bp, dave.hansen, easwar.hariharan, hpa, iommu,
jacob.jun.pan, joro, jpb, kas, kees, linux-arm-kernel,
linux-kernel, mingo, nicolinc, peterz, praan, robin.murphy,
ryasuoka, smostafa, sohil.mehta, tglx, will, x86, xin
On Mon, May 25, 2026 at 03:29:24PM +0000, Joonwon Kang wrote:
> Currently, the only known expected user of the new kAPI is our team. Since
> I test if the patch resolves our problem before sending it, I believe it
> should be good enough. Do you mean more than our team by "accompanied
> users"?
He means you cannot send patches like this that only serve OOT drivers
to the mainline kernel.
Jason
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2] iommu: Allow device driver to use its own PASID space for SVA
2026-05-25 16:47 ` Jason Gunthorpe
@ 2026-05-26 6:58 ` Joonwon Kang
2026-05-26 7:21 ` Tian, Kevin
0 siblings, 1 reply; 12+ messages in thread
From: Joonwon Kang @ 2026-05-26 6:58 UTC (permalink / raw)
To: jgg
Cc: Alexander.Grest, alexander.shishkin, amhetre, baolu.lu, bp,
dave.hansen, easwar.hariharan, hpa, iommu, jacob.jun.pan,
joonwonkang, joro, jpb, kas, kees, kevin.tian, linux-arm-kernel,
linux-kernel, mingo, nicolinc, peterz, praan, robin.murphy,
ryasuoka, smostafa, sohil.mehta, tglx, will, x86, xin
> On Mon, May 25, 2026 at 03:29:24PM +0000, Joonwon Kang wrote:
>
> > Currently, the only known expected user of the new kAPI is our team. Since
> > I test if the patch resolves our problem before sending it, I believe it
> > should be good enough. Do you mean more than our team by "accompanied
> > users"?
>
> He means you cannot send patches like this that only serve OOT drivers
> to the mainline kernel.
Hmm, it gets back to the chicken-and-egg problem. So, do you recommend
deferring the patch submission until we find a new in-tree user of the
new kAPI? I believe we will not make our module in-tree anytime soon.
Or, is it like I still can send the patch and get it reviewed although we
cannot merge it to the mainline?
Thanks,
Joonwon Kang
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [PATCH v2] iommu: Allow device driver to use its own PASID space for SVA
2026-05-26 6:58 ` Joonwon Kang
@ 2026-05-26 7:21 ` Tian, Kevin
2026-05-26 8:44 ` Joonwon Kang
2026-05-26 12:36 ` Joonwon Kang
0 siblings, 2 replies; 12+ messages in thread
From: Tian, Kevin @ 2026-05-26 7:21 UTC (permalink / raw)
To: Joonwon Kang, jgg@ziepe•ca
Cc: Alexander.Grest@microsoft•com, alexander.shishkin@linux•intel.com,
amhetre@nvidia•com, baolu.lu@linux•intel.com, bp@alien8•de,
dave.hansen@linux•intel.com, easwar.hariharan@linux•microsoft.com,
hpa@zytor•com, iommu@lists•linux.dev,
jacob.jun.pan@linux•intel.com, joro@8bytes•org, jpb@kernel•org,
kas@kernel•org, kees@kernel•org,
linux-arm-kernel@lists•infradead.org,
linux-kernel@vger•kernel.org, mingo@redhat•com,
nicolinc@nvidia•com, peterz@infradead•org, praan@google•com,
robin.murphy@arm•com, ryasuoka@redhat•com, smostafa@google•com,
Mehta, Sohil, tglx@kernel•org, will@kernel•org, x86@kernel•org,
xin@zytor•com
> From: Joonwon Kang <joonwonkang@google•com>
> Sent: Tuesday, May 26, 2026 2:58 PM
>
> > On Mon, May 25, 2026 at 03:29:24PM +0000, Joonwon Kang wrote:
> >
> > > Currently, the only known expected user of the new kAPI is our team.
> Since
> > > I test if the patch resolves our problem before sending it, I believe it
> > > should be good enough. Do you mean more than our team by
> "accompanied
> > > users"?
> >
> > He means you cannot send patches like this that only serve OOT drivers
> > to the mainline kernel.
>
> Hmm, it gets back to the chicken-and-egg problem. So, do you recommend
> deferring the patch submission until we find a new in-tree user of the
> new kAPI? I believe we will not make our module in-tree anytime soon.
> Or, is it like I still can send the patch and get it reviewed although we
> cannot merge it to the mainline?
>
It's not chicken-and-egg problem. Just always send them together.
so let's wait until your module is ready for in-tree review...
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [PATCH v2] iommu: Allow device driver to use its own PASID space for SVA
2026-05-26 7:21 ` Tian, Kevin
@ 2026-05-26 8:44 ` Joonwon Kang
2026-05-26 12:36 ` Joonwon Kang
1 sibling, 0 replies; 12+ messages in thread
From: Joonwon Kang @ 2026-05-26 8:44 UTC (permalink / raw)
To: kevin.tian
Cc: Alexander.Grest, alexander.shishkin, amhetre, baolu.lu, bp,
dave.hansen, easwar.hariharan, hpa, iommu, jacob.jun.pan, jgg,
joonwonkang, joro, jpb, kas, kees, linux-arm-kernel, linux-kernel,
mingo, nicolinc, peterz, praan, robin.murphy, ryasuoka, smostafa,
sohil.mehta, tglx, will, x86, xin
> > From: Joonwon Kang <joonwonkang@google•com>
> > Sent: Tuesday, May 26, 2026 2:58 PM
> >
> > > On Mon, May 25, 2026 at 03:29:24PM +0000, Joonwon Kang wrote:
> > >
> > > > Currently, the only known expected user of the new kAPI is our team.
> > Since
> > > > I test if the patch resolves our problem before sending it, I believe it
> > > > should be good enough. Do you mean more than our team by
> > "accompanied
> > > > users"?
> > >
> > > He means you cannot send patches like this that only serve OOT drivers
> > > to the mainline kernel.
> >
> > Hmm, it gets back to the chicken-and-egg problem. So, do you recommend
> > deferring the patch submission until we find a new in-tree user of the
> > new kAPI? I believe we will not make our module in-tree anytime soon.
> > Or, is it like I still can send the patch and get it reviewed although we
> > cannot merge it to the mainline?
> >
>
> It's not chicken-and-egg problem. Just always send them together.
>
> so let's wait until your module is ready for in-tree review...
Alright, thanks. I will wait until any in-tree users show up in the future
and continue working on this then. Please let me know if there is any
request later.
Appreciate all for reviewing the patches from RFC to this point :)
Thanks,
Joonwon Kang
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [PATCH v2] iommu: Allow device driver to use its own PASID space for SVA
2026-05-26 7:21 ` Tian, Kevin
2026-05-26 8:44 ` Joonwon Kang
@ 2026-05-26 12:36 ` Joonwon Kang
2026-05-26 12:39 ` Jason Gunthorpe
1 sibling, 1 reply; 12+ messages in thread
From: Joonwon Kang @ 2026-05-26 12:36 UTC (permalink / raw)
To: kevin.tian, jgg
Cc: Alexander.Grest, alexander.shishkin, amhetre, baolu.lu, bp,
dave.hansen, easwar.hariharan, hpa, iommu, jacob.jun.pan,
joonwonkang, joro, jpb, kas, kees, linux-arm-kernel, linux-kernel,
mingo, nicolinc, peterz, praan, robin.murphy, ryasuoka, smostafa,
sohil.mehta, tglx, will, x86, xin
> > From: Joonwon Kang <joonwonkang@google•com>
> > Sent: Tuesday, May 26, 2026 2:58 PM
> >
> > > On Mon, May 25, 2026 at 03:29:24PM +0000, Joonwon Kang wrote:
> > >
> > > > Currently, the only known expected user of the new kAPI is our team.
> > Since
> > > > I test if the patch resolves our problem before sending it, I believe it
> > > > should be good enough. Do you mean more than our team by
> > "accompanied
> > > > users"?
> > >
> > > He means you cannot send patches like this that only serve OOT drivers
> > > to the mainline kernel.
> >
> > Hmm, it gets back to the chicken-and-egg problem. So, do you recommend
> > deferring the patch submission until we find a new in-tree user of the
> > new kAPI? I believe we will not make our module in-tree anytime soon.
> > Or, is it like I still can send the patch and get it reviewed although we
> > cannot merge it to the mainline?
> >
>
> It's not chicken-and-egg problem. Just always send them together.
>
> so let's wait until your module is ready for in-tree review...
Since adding a new kAPI has this limitation, what do you think about the
idea of adding a new boot parameter to enforce disabling ENQCMD at EL0 and
using the non-global PASID space in that case? This way, I guess we could
resolve our issue without having to wait until we have new in-tree users.
Do you think it should have the same limitation?
Thanks,
Joonwon Kang
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2] iommu: Allow device driver to use its own PASID space for SVA
2026-05-26 12:36 ` Joonwon Kang
@ 2026-05-26 12:39 ` Jason Gunthorpe
2026-05-26 12:46 ` Joonwon Kang
0 siblings, 1 reply; 12+ messages in thread
From: Jason Gunthorpe @ 2026-05-26 12:39 UTC (permalink / raw)
To: Joonwon Kang
Cc: kevin.tian, Alexander.Grest, alexander.shishkin, amhetre,
baolu.lu, bp, dave.hansen, easwar.hariharan, hpa, iommu,
jacob.jun.pan, joro, jpb, kas, kees, linux-arm-kernel,
linux-kernel, mingo, nicolinc, peterz, praan, robin.murphy,
ryasuoka, smostafa, sohil.mehta, tglx, will, x86, xin
On Tue, May 26, 2026 at 12:36:06PM +0000, Joonwon Kang wrote:
> > > From: Joonwon Kang <joonwonkang@google•com>
> > > Sent: Tuesday, May 26, 2026 2:58 PM
> > >
> > > > On Mon, May 25, 2026 at 03:29:24PM +0000, Joonwon Kang wrote:
> > > >
> > > > > Currently, the only known expected user of the new kAPI is our team.
> > > Since
> > > > > I test if the patch resolves our problem before sending it, I believe it
> > > > > should be good enough. Do you mean more than our team by
> > > "accompanied
> > > > > users"?
> > > >
> > > > He means you cannot send patches like this that only serve OOT drivers
> > > > to the mainline kernel.
> > >
> > > Hmm, it gets back to the chicken-and-egg problem. So, do you recommend
> > > deferring the patch submission until we find a new in-tree user of the
> > > new kAPI? I believe we will not make our module in-tree anytime soon.
> > > Or, is it like I still can send the patch and get it reviewed although we
> > > cannot merge it to the mainline?
> > >
> >
> > It's not chicken-and-egg problem. Just always send them together.
> >
> > so let's wait until your module is ready for in-tree review...
>
> Since adding a new kAPI has this limitation, what do you think about the
> idea of adding a new boot parameter to enforce disabling ENQCMD at EL0 and
> using the non-global PASID space in that case? This way, I guess we could
> resolve our issue without having to wait until we have new in-tree users.
> Do you think it should have the same limitation?
No, you can't hack up the kernel for OOT drivers.
Jason
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2] iommu: Allow device driver to use its own PASID space for SVA
2026-05-26 12:39 ` Jason Gunthorpe
@ 2026-05-26 12:46 ` Joonwon Kang
0 siblings, 0 replies; 12+ messages in thread
From: Joonwon Kang @ 2026-05-26 12:46 UTC (permalink / raw)
To: jgg
Cc: Alexander.Grest, alexander.shishkin, amhetre, baolu.lu, bp,
dave.hansen, easwar.hariharan, hpa, iommu, jacob.jun.pan,
joonwonkang, joro, jpb, kas, kees, kevin.tian, linux-arm-kernel,
linux-kernel, mingo, nicolinc, peterz, praan, robin.murphy,
ryasuoka, smostafa, sohil.mehta, tglx, will, x86, xin
> On Tue, May 26, 2026 at 12:36:06PM +0000, Joonwon Kang wrote:
> > > > From: Joonwon Kang <joonwonkang@google•com>
> > > > Sent: Tuesday, May 26, 2026 2:58 PM
> > > >
> > > > > On Mon, May 25, 2026 at 03:29:24PM +0000, Joonwon Kang wrote:
> > > > >
> > > > > > Currently, the only known expected user of the new kAPI is our team.
> > > > Since
> > > > > > I test if the patch resolves our problem before sending it, I believe it
> > > > > > should be good enough. Do you mean more than our team by
> > > > "accompanied
> > > > > > users"?
> > > > >
> > > > > He means you cannot send patches like this that only serve OOT drivers
> > > > > to the mainline kernel.
> > > >
> > > > Hmm, it gets back to the chicken-and-egg problem. So, do you recommend
> > > > deferring the patch submission until we find a new in-tree user of the
> > > > new kAPI? I believe we will not make our module in-tree anytime soon.
> > > > Or, is it like I still can send the patch and get it reviewed although we
> > > > cannot merge it to the mainline?
> > > >
> > >
> > > It's not chicken-and-egg problem. Just always send them together.
> > >
> > > so let's wait until your module is ready for in-tree review...
> >
> > Since adding a new kAPI has this limitation, what do you think about the
> > idea of adding a new boot parameter to enforce disabling ENQCMD at EL0 and
> > using the non-global PASID space in that case? This way, I guess we could
> > resolve our issue without having to wait until we have new in-tree users.
> > Do you think it should have the same limitation?
>
> No, you can't hack up the kernel for OOT drivers.
Alright, thanks for the confirmation.
Thanks,
Joonwon Kang
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2026-05-26 12:47 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-05-20 15:07 [PATCH v2] iommu: Allow device driver to use its own PASID space for SVA Joonwon Kang
2026-05-21 7:39 ` Baolu Lu
2026-05-21 8:25 ` Joonwon Kang
2026-05-25 8:10 ` Tian, Kevin
2026-05-25 15:29 ` Joonwon Kang
2026-05-25 16:47 ` Jason Gunthorpe
2026-05-26 6:58 ` Joonwon Kang
2026-05-26 7:21 ` Tian, Kevin
2026-05-26 8:44 ` Joonwon Kang
2026-05-26 12:36 ` Joonwon Kang
2026-05-26 12:39 ` Jason Gunthorpe
2026-05-26 12:46 ` Joonwon Kang
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox