Re: [PATCH v2 7/7] arm64/sve: Don't zero non-FPSIMD register state on syscall by default

From: Catalin Marinas <catalin.marinas@arm.com>
To: Mark Brown <broonie@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>,
	Zhang Lei <zhang.lei@jp.fujitsu.com>,
	Andre Przywara <andre.przywara@arm.com>,
	Will Deacon <will@kernel.org>,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 7/7] arm64/sve: Don't zero non-FPSIMD register state on syscall by default
Date: Tue, 19 Jul 2022 18:35:37 +0100	[thread overview]
Message-ID: <YtbraaDE0eJhRHkx@arm.com> (raw)
In-Reply-To: <20220620124158.482039-8-broonie@kernel.org>

Hi Mark,

On Mon, Jun 20, 2022 at 01:41:58PM +0100, Mark Brown wrote:
> The documented syscall ABI specifies that the SVE state not shared with
> FPSIMD is undefined after a syscall. Currently we implement this by
> always flushing this register state to zero, ensuring consistent
> behaviour but introducing some overhead in the case where we can return
> directly to userspace without otherwise needing to update the register
> state. Take advantage of the flexibility offered by the documented ABI
> and instead leave the SVE registers untouched in the case where can
> return directly to userspace.

Do you have some rough numbers to quantify the gain? I suspect the
vector length doesn't matter much.

Where does the zeroing happen now? IIRC it's only done on a subsequent
trap to SVE and that's a lot more expensive (unless the code has changed
since last time I looked).

So if it's the actual subsequent trap that adds the overhead, maybe
zeroing the regs while leaving TIF_SVE on won't be that bad.

> Since this is a user visible change a new sysctl abi.sve_syscall_clear_regs
> is provided which will restore the current behaviour of flushing the
> unshared register state unconditionally when enabled. This can be
> enabled for testing or to work around problems with applications that
> have been relying on the current flushing behaviour.
> 
> The sysctl is disabled by default since it is anticipated that the risk
> of disruption to userspace is low. As well as being within the
> documented ABI this new behaviour mirrors the standard function call ABI
> for SVE in the AAPCS which should mean that compiler generated code is
> unlikely to rely on the current behaviour, the main risk is from hand
> coded assembly which directly invokes syscalls. The new behaviour is
> also what is currently implemented by qemu user mode emulation.

IIRC both Will and Mark R commented in the past that they'd like the
current de-facto ABI to become the official one. I'll let them comment.

> @@ -183,7 +217,7 @@ static inline void fp_user_discard(void)
>  	if (!system_supports_sve())
>  		return;
>  
> -	if (test_thread_flag(TIF_SVE)) {
> +	if (sve_syscall_regs_clear && test_thread_flag(TIF_SVE)) {
>  		unsigned int sve_vq_minus_one;
>  
>  		sve_vq_minus_one = sve_vq_from_vl(task_get_sve_vl(current)) - 1;

If we leave TIF_SVE on, does it mean that we incur an overhead on
context switching? E.g. something like hackbench with lots of syscalls
communicating between threads would unnecessarily context switch the SVE
state. Maybe there's something handling this but IIUC fpsimd_save()
seems to only check TIF_SVE.

-- 
Catalin
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm