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

[Jason Gunthorpe <jgg@ziepe.ca>]

On Wed, May 13, 2026 at 05:03:33PM +0000, Joonwon Kang wrote:
> > 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. 

You shouldn't need to do anything like this. 

All you need is to ensure that mm_get_enqcmd_pasid() returns
IOMMU_PASID_INVALID so long as a the normal iommu_sva_bind_device()
hasn't been called. Once it is called it is fine to allow the ENQCMD.

Your new iommu_sva_bind_device_pasid() needs to establish the SVA and
attach it without triggering mm_get_enqcmd_pasid().

The arch code is required to block the ENQCMD like instructions when
IOMMU_PASID_INVALID.

Devices that can mmap an ENQCMD sensitive BAR region must not do so
unless iommu_sva_bind_device() has been called.

> To allocate a per-device PASID, I think we should do it using
> `dev->iommu_group->pasid_array` instead of making the device driver

No, make the driver manage this, don't mess with the core code. PASID
isn't supported with multi-device groups already.

Jason