From: Marc Zyngier <maz@kernel.org>
To: Joey Gouly <joey.gouly@arm.com>
Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
kvm@vger.kernel.org, Steffen Eiden <seiden@linux.ibm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Oliver Upton <oupton@kernel.org>,
Zenghui Yu <yuzenghui@huawei.com>,
Mark Rutland <mark.rutland@arm.com>,
Will Deacon <will@kernel.org>, Fuad Tabba <tabba@google.com>
Subject: Re: [PATCH v2 2/2] KVM: arm64: nv: Don't save/restore FP register during a nested ERET or exception
Date: Thu, 21 May 2026 07:21:41 +0100 [thread overview]
Message-ID: <86o6i9wadm.wl-maz@kernel.org> (raw)
In-Reply-To: <20260520110231.GA4005903@e124191.cambridge.arm.com>
On Wed, 20 May 2026 12:02:31 +0100,
Joey Gouly <joey.gouly@arm.com> wrote:
>
> Hi Marc,
>
> On Wed, May 20, 2026 at 09:50:36AM +0100, Marc Zyngier wrote:
> > When switching between L1 and L2, we save the old state using
> > kvm_arch_vcpu_put(), mutate the state in memory, then load the new
> > state using kvm_arch_vcpu_load(). Any live FPSIMD/SVE state is saved
> > and unbound, such that it can be lazily restored on a subsequent trap.
> >
> > The FPSIMD/SVE state is shared by exception levels, and only a handful
> > of related control registers need to be changed when transitioning
> > between L1 and L2. The save/restore of the common state is needless
> > overhead, especially as trapping becomes exponentially more expensive
> > with nesting.
> >
> > Avoid this overhead by leaving the common FPSIMD/SVE state live on the
> > CPU, and only switching the state that is distinct for L1 and L2:
>
> To make sure I understand this part:
>
> L1 sets up L2's FP state live on the CPU
> L1 erets
> eret traps to L0/host
> preemption disabled
> kvm_arch_vcpu_put()
> kvm_arch_vcpu_put_fp() <-- actually saves the state of the live registers
> .. set elr etc ..
> kvm_arch_vcpu_load()
> kvm_arch_vcpu_load_fp() <-- doesn't actually restore state, but ensures
> the CPTR trap will be set
> .. returns to L2 (traps on first use of FP and state will be restored)
>
> So this patch is (effectively) removing the put_fp()/load_fp(), because the FP
> state is common/shared between L1 and L2, so whatever L1 put into that state
> before the eret, L2 was going to see.
Yes, you got it right. The other path is on L1 to L2 exception, which
also requires L0 mediation and has a similar shape.
The most horrible thing is that because all these traps can happen at
a arbitrary depth, each individual trap usually results in the
combination of all of the above.
> If my understanding is correct:
> Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Thanks!
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2026-05-21 6:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-20 8:50 [PATCH v2 0/2] KVM: arm64: nv: Reduce FP/SVE overhead on exception/exception return Marc Zyngier
2026-05-20 8:50 ` [PATCH v2 1/2] KVM: arm64: nv: Track L2 to L1 exception emulation Marc Zyngier
2026-05-20 8:50 ` [PATCH v2 2/2] KVM: arm64: nv: Don't save/restore FP register during a nested ERET or exception Marc Zyngier
2026-05-20 11:02 ` Joey Gouly
2026-05-21 6:21 ` Marc Zyngier [this message]
2026-05-20 13:02 ` Mark Rutland
2026-05-21 6:35 ` Marc Zyngier
2026-05-21 7:07 ` [PATCH v2 0/2] KVM: arm64: nv: Reduce FP/SVE overhead on exception/exception return Marc Zyngier
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=86o6i9wadm.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=joey.gouly@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=oupton@kernel.org \
--cc=seiden@linux.ibm.com \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.