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

Marc Zyngier maz at kernel.org
Wed May 20 23:21:41 PDT 2026


On Wed, 20 May 2026 12:02:31 +0100,
Joey Gouly <joey.gouly at 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 at arm.com>

Thanks!

	M.

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



More information about the linux-arm-kernel mailing list