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

[Joonwon Kang <joonwonkang@google.com>]

Hi Jason and Robin, thanks a lot for sharing your insights! Could you help
to answer the further questions below? or just let me know if it is better
to use other channels for them like ARM support.

> On Mon, May 11, 2026 at 01:39:06PM +0100, Robin Murphy wrote:
> > On 2026-05-09 6:10 pm, Jason Gunthorpe wrote:
> > > On Thu, May 07, 2026 at 09:58:51AM +0000, Joonwon Kang wrote:
> > > 
> > > > By "similar instruction" on ARM, I guess you mean ST64BV0, which fetches
> > > > the bottom 32 bits data from ACCDATA_EL1. Please let me know if you meant
> > > > others as it will matter. If ST64BV0 is supported on ARM, however, it
> > > > would mean that ST64B and ST64BV are also supported already according to
> > > > the ID_AA64ISAR1_EL1's LS64 field. The latter 2 instructions are just to
> > > > atomically store whatever user wants to a memory location without
> > > > referring to ACCDATA_EL1 and all the 3 instructions can be run at EL0. So,
> > > > the userspace driver would have enough capability to designate arbitrary
> > > > PASID as it wants via the latter 2 instructions when communicating with
> > > > multiple devices.
> > > 
> > > IDK exactly what ARM did. IIRC on Intel ENQCMD forms a special
> > > non-posted write TLP and the device can tell the TLP came from ENQCMD
> > > and so it trusts the encoded PASID. ARM has to have done the same
> > > thing - allowing anyone to forge the PASID by using a different
> > > instruction misses the point of the Intel design.
> > 
> > Yes, ACCDATA_EL1 is a privileged register neither writeable nor readable by
> > userspace[1], so it should be functionally equivalent from an SVA point of
> > view.
> 
> 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.

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 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].

[1] https://github.com/torvalds/linux/blob/50897c955902c93ae71c38698abb910525ebdc89/arch/arm64/kernel/cpufeature.c#L3166-L3181

Thanks,
Joonwon Kang