[PATCH v7 5/7] arm64: Add support for FEAT_{LS64, LS64_V}

[Arnd Bergmann]

On Tue, Nov 18, 2025, at 03:31, Zhou Wang wrote:
> On 2025/11/14 17:37, Arnd Bergmann wrote:
>> On Fri, Nov 14, 2025, at 10:25, Zhou Wang wrote:
>>> On 2025/11/14 0:26, Arnd Bergmann wrote:
>>>>
>>>> Are you using a particular device, or are you trying to enable
>>>> the support in general? If you have a specific device you are
>>>> working on, does it use the PASID data or not?
>>>
>>> Many thanks for your careful explanation! I got the pointer here.
>>>
>>> We have a real device in our SoC, which supports LS64B/ST64B/ST64BV.
>>> For ST64BV, Our device just receives 64B data atomically, not interpret
>>> it with PASID data.
>> 
>> Ok, I see. So I assume this is either a kind of dedicated work queue
>> where the IOMMU PASID is set up in advance for the user MMIO area,
>
> Yeah, it is something like you mentioned above. MMIO area is binded with
> a work queue, a PASID is set up in advance for this work queue.

Ok, thanks for confirming.

>> or it is a device that does not do any DMA at all, correct?
>> 
>> In this case, would the device also work correctly with ST64BV0 if
>> the ACCDATA register is fixed to a value of zero and you can only
>> use the upper 480 bits? Would it also work if there is an
>> unpredictable value in ACCDATA that may match the PASID of another
>> device used by the same process?
>
> We do not support ST64BV0, so above case will not happen. I think ST64BV0
> will trigger a illegal instruction exception in our system.

At least this does make it easier because on your system you would
never run into a situation where you want to support both your
internal device with st64bv and another device with st64bv0.

The easiest setup I can think of that still supports your machine
would look something like:

- have the kernel choose between st64bv and st64bv0 at early boot,
  based on platform configuration, use st64bv0 by default if
  available in hardware and not disabled in EL3, EL2 or kernel
  command line.
- Change pasid handling in iommu_sva_bind_device() so drivers
  have to explicitly request one of the modes before establishing
  a pasid, refuse this on incompatible systems, update the
  three existing callers (idxd, amdxdna, uacce) accordingly.
- on systems with st64bv but no st64bv0, enable st64bv for
  all CPUs at boot time to avoid context switch overhead, but
  forbid mapping shared hardware workqueues into userspace.
- postpone full support for st64bv0 until we have a device that
  actually uses this and can be tested. I think most of it is
  already there in the iommu code, but the ACCDATA setup needs
  to be integrated into the switch_mm()/__switch_to() code
  and possibly a trap handler like on x86.

In the current architecture, both FEAT_LS64_V and
FEAT_LS64_ACCDATA are optional, so you can continue to
produce CPUs that have the former but not the latter, and
the logic above will keep that working. However this breaks
if you ever want to support FEAT_LS64_ACCDATA in a later
CPU but keep the existing driver working with st64bv.

       Arnd