[PATCH] KVM: arm64/sve: Ensure SVE is trapped after guest exit

[Mark Brown]

On Tue, Jan 21, 2025 at 11:20:04AM +0000, Marc Zyngier wrote:
> Mark Rutland <mark.rutland at arm.com> wrote:

> > +		/*
> > +		 * The KVM hyp code doesn't set fp_type when saving the host's
> > +		 * FPSIMD state. Set fp_type here in case the hyp code saves
> > +		 * the host state.

> Should KVM do that? The comment seems to indicate that this is
> papering over yet another bug...

It should, we need to record what format the data we saved was in so
that if the saved state is loaded we load what we actually saved.

> > +		 * If hyp code does not save the host state, then the host
> > +		 * state remains live on the CPU and saved fp_type is
> > +		 * irrelevant until it is overwritten by a later call to
> > +		 * fpsimd_save_user_state().

> I'm not sure I understand this. If fp_type is irrelevant, surely it is
> *forever* irrelevant, not until something else happens. Or am I
> missing something?

The confusion stems from the fact that the setting of fp_type is done
separately to the actual state save since we don't map fp_type to the
hypervisor.  Either we don't save in KVM, in which case any later save
in the host kernel will write both state and fp_type, or we save in KVM
in which case this results in the correct fp_type being set.  In both
cases we have live state in the registers and whatever is currently in
memory should be considered stale and it's not the end of the world if
it's corrupt.  It would be a lot more straightforward if we wrote
fp_type from the hypervisor as part of the save.

I want to rework the way we represent the state so that we don't have
the state spread around like this, avoiding the need to map individual
parts of it separately to the hypervisor.  We need something like that
to sensibly implement in kernel SVE/SME which we will need at some
point.
-------------- 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/20250121/ae8925cd/attachment.sig>