From: Mark Rutland <mark.rutland@arm.com>
To: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org, broonie@kernel.org,
catalin.marinas@arm.com, eauger@redhat.com,
eric.auger@redhat.com, fweimer@redhat.com, jeremy.linton@arm.com,
maz@kernel.org, oliver.upton@linux.dev, pbonzini@redhat.com,
stable@vger.kernel.org, tabba@google.com, wilco.dijkstra@arm.com
Subject: Re: [PATCH v2 1/8] KVM: arm64: Unconditionally save+flush host FPSIMD/SVE/SME state
Date: Fri, 7 Feb 2025 13:21:44 +0000 [thread overview]
Message-ID: <Z6YI6IvG_N4txgz7@J2N7QTR9R3> (raw)
In-Reply-To: <20250207122748.GA4839@willie-the-truck>
On Fri, Feb 07, 2025 at 12:27:51PM +0000, Will Deacon wrote:
> 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:
> >
> > https://issues.redhat.com/browse/RHEL-68997
> >
> > * 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?
For the first case I have a quick and dirty test, which I've pushed to
my arm64/kvm/fpsimd-tests branch in my kernel.org repo:
https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/
git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git
For the last case it should be possible to do something similar, but I
hadn't had the time to dig in to the KVM selftests infrastructure and
figure out how to confiugre the guest appropriately.
For the ptrace case, the same symptoms can be provoked outside of KVM
(and I'm currently working to fix that). From my PoV the important thing
is that this fix happens to remove KVM from the set of cases the other
fixes need to care about.
FWIW I was assuming that I'd be handling the upstream backports, and I'd
be testing with the test above and some additional assertions hacked
into the kernel for testing.
Mark.
next prev parent reply other threads:[~2025-02-07 13:23 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-06 14:10 [PATCH v2 0/8] KVM: arm64: FPSIMD/SVE/SME fixes Mark Rutland
2025-02-06 14:10 ` [PATCH v2 1/8] KVM: arm64: Unconditionally save+flush host FPSIMD/SVE/SME state Mark Rutland
2025-02-07 12:27 ` Will Deacon
2025-02-07 13:21 ` Mark Rutland [this message]
2025-02-10 10:53 ` Marc Zyngier
2025-02-10 15:05 ` Will Deacon
2025-02-06 14:10 ` [PATCH v2 2/8] KVM: arm64: Remove host FPSIMD saving for non-protected KVM Mark Rutland
2025-02-10 16:12 ` Will Deacon
2025-02-10 16:59 ` Mark Rutland
2025-02-10 18:06 ` Will Deacon
2025-02-10 20:03 ` Mark Rutland
2025-02-11 19:08 ` Mark Rutland
2025-02-06 14:10 ` [PATCH v2 3/8] KVM: arm64: Remove VHE host restore of CPACR_EL1.ZEN Mark Rutland
2025-02-10 16:14 ` Will Deacon
2025-02-06 14:10 ` [PATCH v2 4/8] KVM: arm64: Remove VHE host restore of CPACR_EL1.SMEN Mark Rutland
2025-02-10 16:16 ` Will Deacon
2025-02-06 14:10 ` [PATCH v2 5/8] KVM: arm64: Refactor CPTR trap deactivation Mark Rutland
2025-02-10 16:34 ` Will Deacon
2025-02-06 14:11 ` [PATCH v2 6/8] KVM: arm64: Refactor exit handlers Mark Rutland
2025-02-10 16:37 ` Will Deacon
2025-02-06 14:11 ` [PATCH v2 7/8] KVM: arm64: Mark some header functions as inline Mark Rutland
2025-02-10 16:39 ` Will Deacon
2025-02-06 14:11 ` [PATCH v2 8/8] KVM: arm64: Eagerly switch ZCR_EL{1,2} Mark Rutland
2025-02-06 19:12 ` Mark Brown
2025-02-07 9:34 ` Mark Rutland
2025-02-10 16:53 ` Will Deacon
2025-02-10 17:21 ` Mark Rutland
2025-02-10 18:20 ` Will Deacon
2025-02-10 18:56 ` Mark Rutland
2025-02-11 10:29 ` Will Deacon
2025-02-08 0:27 ` [PATCH v2 0/8] KVM: arm64: FPSIMD/SVE/SME fixes Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z6YI6IvG_N4txgz7@J2N7QTR9R3 \
--to=mark.rutland@arm.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=eauger@redhat.com \
--cc=eric.auger@redhat.com \
--cc=fweimer@redhat.com \
--cc=jeremy.linton@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=pbonzini@redhat.com \
--cc=stable@vger.kernel.org \
--cc=tabba@google.com \
--cc=wilco.dijkstra@arm.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox