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

[Mark Brown]

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.

> > +		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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20221207/60826d45/attachment.sig>