RE: [PATCH v2] iommu: Allow device driver to use its own PASID space for SVA

[Tian, Kevin]

> From: Joonwon Kang <joonwonkang@xxxxxxxxxx>
> 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@xxxxxxxx>
> Suggested-by: Kevin Tian <kevin.tian@xxxxxxxxx>
> Signed-off-by: Joonwon Kang <joonwonkang@xxxxxxxxxx>
> ---
> 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.