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

[Joonwon Kang <joonwonkang@google.com>]

> On 12/05/2026 1:40 pm, Jason Gunthorpe wrote:
> > 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.
> 
> Yes, I think it's rather the point that the EnALS/EnASR traps to EL1 
> allow EL1 to sanitise the data that ST64B/ST64BV are sending, and do 
> exactly things like substituting a valid PASID. ST64BV0 offers a way of 
> doing so _without_ needing the overhead of trapping, but conversely that 
> needs the EnAS0 opt-in all the way down to indicate both EL1's awareness 
> of programming ACCDATA_EL1 appropriately and EL2/3's awareness of 
> context-switching it.
> 
> I've not looked closely at what exactly the arm64 arch code is doing 
> today and how well it actually fits the expected ENQCMD usage model, but 
> I can well believe it might need a bit of tweaking.
> 
> Thanks,
> Robin.
> 
> >> 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

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?

If yes, I will create a new patch which checks for that case. It might as
well add a new device tree property to represent if the device supports
the posted write vs. non-posted write distinction.

Thanks,
Joonwon Kang