Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Sender: psodagud=codeaurora.org@mg.codeaurora.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date:   Thu, 20 May 2021 16:02:03 -0700
From:   psodagud@codeaurora.org
To:     catalin.marinas@arm.com, will@kernel.org, Dave.Martin@arm.com,
        amit.kachhap@arm.com
Cc:     linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: sve_user_discard
Message-ID: <785d7bc29da6bff0dceeb712c24601fd@codeaurora.org>
User-Agent: Roundcube Webmail/1.3.9
Precedence: bulk

Hi All,

This is regarding sve_user_disable(CPACR_EL1_ZEN_EL0EN) on every system 
call.  If a userspace task is using SVE instructions and making sys 
calls in between, it would impact the performance of the thread. On 
every SVE instructions after SVC/system call, it would trap to EL1.

I think by setting CPACR_EL1_ZEN_EL0EN flag,  the processor faults when 
it runs an SVE instruction. This approach may be taken as part of FPSIMD 
registers switching optimizations.  Can below portion of the code use 
thread.fpsimd_cpu and fpsimd_last_state variables to avoid clearing 
CPACR_EL1_ZEN_EL0EN for this kind of use cases?

static inline void sve_user_discard(void)
{
	if (!system_supports_sve())
		return;

	clear_thread_flag(TIF_SVE);

	/*
	 * task_fpsimd_load() won't be called to update CPACR_EL1 in
	 * ret_to_user unless TIF_FOREIGN_FPSTATE is still set, which only
	 * happens if a context switch or kernel_neon_begin() or context
	 * modification (sigreturn, ptrace) intervenes.
	 * So, ensure that CPACR_EL1 is already correct for the fast-path case.
	 */
	sve_user_disable();
}

-Thanks, Prasad