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

[Arnd Bergmann]

On Thu, Nov 27, 2025, at 04:51, Zhou Wang wrote:
> On 2025/11/18 15:36, Arnd Bergmann wrote:
>> On Tue, Nov 18, 2025, at 03:31, Zhou Wang wrote:
>>
>> 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.

As I understand it, using ST64B is usually more efficient than
ST64BV if you can use either, since it is a normal posted bus
transaction rather than a synchronous atomic. If that works for
you, I think what we should plan for is to let you use ST64B
on this particular hardware and never support ST64BV from
userspace, the same way we do it on Intel hardware with ENQCMD.

As there are already CPUs out there that do include ST64BV0,
I think we also want to support those soon. Not having to
support both ST64BV and ST64BV0 from userspace makes it a lot
easier, but I think we'd still want to only enable ST64BV0
on a per-task base when mapping a shared workqueued into the
user address space on a task that has an active mm->iommu_mm.

If that makes sense to you, I can try to come up with a
prototype based on your current patches to add the context
switching and enable logic.

      Arnd