Re: [PATCH v14 16/39] arm64/sme: Implement traps and syscall handling for SME

Zenghui Yu
2022-12-08T02:15:38Z

On 2022/12/7 22:16, Mark Brown wrote:
> On Wed, Dec 07, 2022 at 10:00:17PM +0800, Zenghui Yu wrote:
>> On 2022/4/19 19:22, Mark Brown wrote:
>
>>> + /*
>>> + * If SME is active then exit streaming mode. If ZA is active
>>> + * then flush the SVE registers but leave userspace access to
>>> + * both SVE and SME enabled, otherwise disable SME for the
>>> + * task and fall through to disabling SVE too. This means
>
>> It looks a bit confusing to me that in the current implementation, if
>> ZA is *not* active, we don't actually go to disable SME for the task
>> (which IMHO can be disabled as user-space is not actively using it now).
>
> Unlike SVE there's no overhead from leaving SME enabled, the enable bits
> for SM and ZA tell us if there is extra register state to be saved so we
> don't have to worry about the costs there like we do with SVE. The only
> reason for not just unconditionally enabling SME is the potentially
> large backing storage required for the registers, if a task isn't using
> SME there's no need to impose that overhead. If we disable SME for
> userspace after the storage has been allocated then we just require an
> additional trip through EL1 to reenable it for any future usage which
> would hurt performance but not really gain us anything otherwise. We
> don't want to discurage applications from disabling ZA when not in use
> given that there's likely to be physical overheads from keeping it
> enabled.

Ah, thanks a lot for the explanations. The comment itself can be
improved though (I think).

>>> + if (svcr & SYS_SVCR_EL0_SM_MASK)
>>> + sme_smstop_sm();
>
>> As per the SME syscall ABI
>
>> | On syscall PSTATE.SM will be cleared and the SVE registers will be
>> | handled as per the standard SVE ABI.
>
>> and the SVE syscall ABI
>
>> | On syscall, V0..V31 are preserved (as without SVE). Thus, bits
>> | [127:0] of Z0..Z31 are preserved. All other bits of Z0..Z31, and all
>> | of P0..P15 and FFR become zero on return from a syscall.
>
>> Can we infer from the documentation that V0-V31 should be preserved on
>> return from a syscall? But with sme_smstop_sm(), all implemented bits of
>> Z0-Z31 are set to zero by hardware. Is this intentional?
>
>> Please fix me up if I've mis-read things here.
>
> No, the intention is to say that we exit streaming mode and then handle
> things as per the non-streaming ABI. Exiting streaming mode has the
> effect of clearing the values as you say.

Thanks,
Zenghui