On Thu, Feb 06, 2025 at 02:10:55PM +0000, Mark Rutland wrote:
There are several problems with the way hyp code lazily saves the host's FPSIMD/SVE state, including:
Host SVE being discarded unexpectedly due to inconsistent configuration of TIF_SVE and CPACR_ELx.ZEN. This has been seen to result in QEMU crashes where SVE is used by memmove(), as reported by Eric Auger:
Host SVE state is discarded *after* modification by ptrace, which was an unintentional ptrace ABI change introduced with lazy discarding of SVE state.
The host FPMR value can be discarded when running a non-protected VM, where FPMR support is not exposed to a VM, and that VM uses FPSIMD/SVE. In these cases the hyp code does not save the host's FPMR before unbinding the host's FPSIMD/SVE/SME state, leaving a stale value in memory.
How hard would it be to write tests for these three scenarios? If we had something to exercise the relevant paths then...
... and so this eager save+flush probably needs to be backported to ALL stable trees.
... this backporting might be a little easier to be sure about?
Will