Subject: Re: [PATCH v2 2/2] KVM: arm64: nv: Don't save/restore FP register during a nested ERET or exception

From: Marc Zyngier <[email-masked]>
Date: Thu, 21 May 2026 07:21:41 +0100

On Wed, 20 May 2026 12:02:31 +0100,
Joey Gouly <[email-masked]> 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 <[email-masked]>

Thanks!

	M.

-- 
Without deviation from the norm, progress is not possible.