While testing an unrelated pmap change, D58708, that dramatically
reduces the number of TLBI instructions performed, and likely the
timing of unrelated events, I started seeing "Storing an invalid VFP
state" panics in vfp_save_state_common(). However, the origin of the
panic is in the else branch of sve_restore_state(). Specifically, my
pmap change seems to have increased the likelihood that the thread
executing the else branch would be preempted by another thread between
the critical_exit() inside its call to vfp_restore_state_common() and
the else branch's own critical_enter(). Prior to expanding the scope
of the else branch's critical section, the MPASS added by this change
would fire, catching the problem at its source, rather than later in
vfp_save_state_common().

Assisted-by: Claude Code (Opus 5)