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

[Joonwon Kang]

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 at ziepe.ca>
> > Suggested-by: Kevin Tian <kevin.tian at intel.com>
> > Signed-off-by: Joonwon Kang <joonwonkang at 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