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

[Jason Gunthorpe <jgg@ziepe.ca>]

On Tue, May 12, 2026 at 09:57:14AM +0000, Joonwon Kang wrote:
> > There is a bit more going on though, I think that is what Joonwon is
> > mentioning by asking about ST64B and ST64BV. I *think* the answer is:
> > 
> > - ST64B uses a posted write
> > - ST64BV can be restricted so EL0 cannot execute it, it uses a
> >   non-posted write (AI tells me via EnASR)
> > - ST64BV0 can be used by EL0, always uses a non-posted write, and always
> >   uses ACCDATA_EL1
> > 
> > Which is similar to Intel.
> 
> Ah, I missed that ST64BV is currently being trapped to EL1 while ST64B is
> not [1]. However, I am not sure if the trap is to disallow EL0 to use it.
> Can it be instead to pass the response value of the non-posted write to
> EL0 while using the EL0-given PASID as-is? If so, I believe EL0 still can
> specify arbitrary PASID as it wants via ST64BV.

I think if an OS implements things this way it is would security
broken as far as ENQCMD compatible HW goes.

> Since I guess ST64B* instructions are to serve generic purposes not only
> for communication with accelerators with SIOV but also with any memory
> location or device without SIOV, I am not sure if it is always okay to
> make those instructions work the way Jason mentioned.

The end point has to use the posted vs non-posted write distinction
for security.

> > The device only processes the PASID from a non-posted write,
> 
> Regarding ST64B, are the ARM devices behind ARM SMMU v3 supposed to work
> this way too? If not, EL0 can specify arbitrary PASID via ST64B with the
> kernel today [1].

If you want ENQCMD compatible semantics then yes you have to do all of
these things, it is part of the security design.

Jason