Re: [RFC PATCH v2 7/8] arm64/sve: Don't disable SVE on syscalls return

From: Catalin Marinas <catalin.marinas@arm.com>
To: Dave Martin <Dave.Martin@arm.com>
Cc: Anton.Kirilov@arm.com, will.deacon@arm.com, oleg@redhat.com,
	zhang.lei@jp.fujitsu.com, Julien Grall <julien.grall@arm.com>,
	alex.bennee@linaro.org, linux-arm-kernel@lists.infradead.org,
	Daniel.Kiss@arm.com
Subject: Re: [RFC PATCH v2 7/8] arm64/sve: Don't disable SVE on syscalls return
Date: Thu, 4 Jul 2019 15:15:59 +0100	[thread overview]
Message-ID: <20190704141559.GA51773@arrakis.emea.arm.com> (raw)
In-Reply-To: <20190621153316.GC2790@e103592.cambridge.arm.com>

On Fri, Jun 21, 2019 at 04:33:16PM +0100, Dave P Martin wrote:
> On Thu, Jun 13, 2019 at 05:16:55PM +0100, Julien Grall wrote:
> > Per the syscalls ABI, SVE registers will be unknown after a syscalls. In
> 
> This patch is quite hard to understand, though this is more down to the
> code being modified than the patch itself.  So, I may ask some stupid
> questions...
> 
> In particular, we now have up to 8 task states (all the combinations of
> TIF_FOREIGN_FPSTATE, TIF_SVE and TIF_SVE_NEEDS_FLUSH).  Sketching out
> the state machine and highlighting any states that we consider invalid
> may be a useful exercise, but I've not attempted that yes.

We definitely need a state machine sketched out (and a formal model as I
can't really get all of it in my head at once). I don't fully understand
the need for a new TIF_SVE_NEEDS_FLUSH. Maybe it becomes obvious if we
had a state machine description.

So, we currently have (IIUC):

TIF_SVE - tells us whether the user space can access SVE registers
without a fault (doesn't CPACR_EL1 tell us this already on kernel entry?
I guess we'd need to store it in a TIF flag anyway for switch_to). The
implications of TIF_SVE on kernel entry is that the SVE state could have
been touched by the user. If entering via syscall, we discard this state
in sve_user_discard().

TIF_FOREIGN_FPSTATE - tells us whether the hardware state is out of sync
with the current thread.

For flushing the SVE state on return from syscall, can we not handle
this entirely in el0_svc_handler while enabling the SVE access at the
same time to avoid a subsequent trap? We need to know whether the SVE
state is valid when we do the context switching but we have TIF_SVE for
this, cleared on syscall entry but can be set again on return from
syscall if we enable access in CPACR_EL1 (sve_user_enable()).

It probably needs some more thinking on signal handling.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel