[PATCH v2 2/5] KVM: arm64: Get rid of host SVE tracking/saving

Mark Brown broonie at kernel.org
Thu Oct 28 06:02:50 PDT 2021


On Thu, Oct 28, 2021 at 12:16:37PM +0100, Marc Zyngier wrote:
> The SVE host tracking in KVM is pretty involved. It relies on a
> set of flags tracking the ownership of the SVE register, as well
> as that of the EL0 access.

> It is also pretty scary: __hyp_sve_save_host() computes
> a thread_struct pointer and obtains a sve_state which gets directly
> accessed without further ado, even on nVHE. How can this even work?

> The answer to that is that it doesn't, and that this is mostly dead
> code. Closer examination shows that on executing a syscall, userspace
> loses its SVE state entirely. This is part of the ABI. Another
> thing to notice is that although the kernel provides helpers such as
> kernel_neon_begin()/end(), they only deal with the FP/NEON state,
> and not SVE.

> Given that you can only execute a guest as the result of a syscall,
> and that the kernel cannot use SVE by itself, it becomes pretty
> obvious that there is never any host SVE state to save, and that
> this code is only there to increase confusion.

Ah, this explains a lot and does in fact make life a lot easier, though
we're going to get some of the fun back for SME since the ABI does not
invalidate ZA on syscall.  That said there we have a register we can
check to see if the state is live rather than having to track what's
going on with TIF.  I've also currently got changes in the SME patch set
which do mean that we won't clear TIF_SVE on syscall entry while SME is
active, however I can rework that to fit in with this change easily
enough which given the simplifications introduced seems like it is
clearly the right thing to do so:

Reviewed-by: Mark Brown <broonie at kernel.org>
-------------- 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/20211028/d79b252c/attachment-0001.sig>


More information about the linux-arm-kernel mailing list