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

[Zhou Wang]

On 2025/11/27 23:37, Arnd Bergmann wrote:
> 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.

I missed the email as it has been filtered into other fold, my bad :(
I think it works fine in our system. I planned to remove whole ST64BV
support in next version, so what you suggested is not to export
ST64BV to userspace?

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

I am OK with this, even though currently we do not have a real
hardware to test ST64BV0 related codes.

Best,
Zhou

> 
>       Arnd
> .