Re: [PATCH RFC] iommu: Enable per-device SSID space for SVA

[Joonwon Kang <joonwonkang@google.com>]

> On Tue, May 12, 2026 at 02:51:38PM +0000, Joonwon Kang wrote:
> 
> > Appreciate all your clarifications here. So, my understanding is that if
> > our system does not support ST64BV and ST64BV0 or if our device does not
> > distinguish between the posted write and the non-posted write regarding
> > PASID, then we can lift the use of the global PASID space. Can I say this?
> 
> You should do what Robin said - just have your driver use a per-device
> PASID that it allocates and never use the global pasid allocator.
> 
> To do this lightly re-organize the SVA code so the driver can supply
> its own PASID, and in this mode we wouldn't activate the ENQCMD
> features in the mm.

Ah, we could actively disallow EL0 to execute ENQCMD-like instructions
when the device driver explicitly shows the intention via a new API like
`iommu_sva_bind_device_pasid()` that Tian mentioned earlier. And the new
API only uses the per-device PASID space. It makes a lot of sense. It also
means that ENQCMD-like instructions are only allowed when the PASID is
allocated from the global PASID space.

If a process communicates with only one device with the PASID allocated
from the per-device PASID space, however, there should be no blocker for
the process to execute ENQCMD-like instructions, technically speaking. In
this case, should we allow the process to execute them? and later if the
process tries to allocate another PASID for another device, should we
disallow the instruction execution then? I guess this way may complicate
the implementation without much benefit, though.

To allocate a per-device PASID, I think we should do it using
`dev->iommu_group->pasid_array` instead of making the device driver
create its own PASID set since all the devices in the same `iommu_group`
are supposed to share the same PASID space.

Will create a new patch with the establishment so far.

Thanks,
Joonwon Kang