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

[Zhou Wang]

On 2025/11/18 15:36, Arnd Bergmann wrote:
> 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.

Hi Arnd,

Sorry for late to reply, I double checked with our SoC and device
colleagues, currently only st64b has been used in our system.

So I think we could upstream FEAT_LS64 firstly as it seems easy
to be merged. After this, we continue to discuss FEAT_LS64V and
FEAT_LS64_ACCDATA solution if there is a real system need them.

Best,
Zhou

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