tree cd04c620707e01976159dc4c3907815e1cce6160
parent 3cea11cd5e3b00d91caf0b4730194039b45c5891
author Julien Grall <julien.grall@arm.com> 1560442615 +0100
committer Mark Brown <broonie@kernel.org> 1604685400 +0000
gpgsig -----BEGIN PGP SIGNATURE-----
 
 iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl+ljm0ACgkQJNaLcl1U
 h9Cfzwf/eo8Yx7mcP/3JIG95SzuOiZwv83bt0A7A7+mgWMUKSrbxFmCIO98FNJ8Y
 2TS2BdIQ/80oeIYqZlgPZmvcchW29JD0sg21BZxMuyfQhi5XlKQBULn3xpOLmqvA
 Nnr0ElrP/nClcSDpRMppcf1QCQigicORZCPxSey/ezpVjB4p4L4i4f6ckt4nBiPV
 v90IsIrZzXMBV6c32SLvz+Oul/0K8HuWd2uJuXQee+b3Y3XCcBoGnc3jhVF+ywC9
 +ES6Eah7ieU+xq0HvMQUofa5JoDZocKVWBSjZJ3BJSGLEByfPHpolgl/T0Tkjxsl
 KlNQdGL73S9lC/L63inniHkY7J1kLQ==
 =JTQX
 -----END PGP SIGNATURE-----

arm64/sve: Don't disable SVE on syscalls return

Per the syscalls ABI the state of the SVE registers is unknown after a
syscall. In practice the kernel will disable SVE and zero all the
registers but the first 128-bits of the vector on the next SVE
instruction. In workloads mixing SVE and syscalls this will result in at
least one extra entry/exit to the kernel per syscall when the SVE
registers are accessed for the first time after the syscall.

To avoid the second entry/exit a new flag TIF_SVE_NEEDS_FLUSH is
introduced to mark a task that needs to flush the SVE context on
return to userspace.

On entry to a syscall the flag TIF_SVE will still be cleared, it will
be restored on return to userspace once the SVE state has been flushed.
This means that if a task requires to synchronize the FP state during a
syscall (e.g context switch, signal) only the FPSIMD registers will be
saved. When the task is rescheduled the SVE state will be loaded from
FPSIMD state.

We could instead handle flushing the SVE state in do_el0_svc() however
doing this reduces the potential for further optimisations such as
initializing the SVE registers directly from the FPSIMD state when
taking a SVE access trap and has some potential edge cases if we
schedule before we return to userspace after do_el0_svc().

Signed-off-by: Julien Grall <julien.grall@arm.com>
[Revisions in response to review comments, mainly clarifications around
documentation -- broonie]
Signed-off-by: Mark Brown <broonie@kernel.org>