Re: [PATCH v2 07/28] KVM: arm64: Don't evaluate HCR_EL2.NV nor HFGITR_EL2.ERET on ERET fast path

[Oliver Upton <oupton@kernel.org>]

On Wed, Jul 15, 2026 at 09:19:09AM +0100, Marc Zyngier wrote:
> On Wed, 15 Jul 2026 09:00:37 +0100,
> Oliver Upton <oupton@kernel.org> wrote:
> > 
> > Hey,
> > 
> > On Tue, Jul 14, 2026 at 10:16:20AM +0100, Marc Zyngier wrote:
> > > We currently avoid using the ERET fast path if the guest has HCR_EL2.NV
> > > set. This is an odd check, as NV doesn't mean much if HCR_EL2.TGE==1.
> > > 
> > > Similarly, evaluating HFGITR_EL2.ERET makes little sense, as
> > > this only applies to the nested context, while the ERET fast-path
> > > is purely for the benefit of L1.
> > > 
> > > Replace these bizarre checks with is_nested_ctxt() which makes a lot
> > > more sense: if we are running an L2, the ERET trap must go to L1.
> > > 
> > > Fixes: dd0717a998f77 ("KVM: arm64: nv: Fast-track 'InHost' exception returns")
> > > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > > ---
> > >  arch/arm64/kvm/hyp/vhe/switch.c | 9 +++------
> > >  1 file changed, 3 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c
> > > index bbe9cebd3d9d5..a83be345f8450 100644
> > > --- a/arch/arm64/kvm/hyp/vhe/switch.c
> > > +++ b/arch/arm64/kvm/hyp/vhe/switch.c
> > > @@ -344,13 +344,10 @@ static bool kvm_hyp_handle_eret(struct kvm_vcpu *vcpu, u64 *exit_code)
> > >  	 * if this is a VHE guest hypervisor returning to its own
> > >  	 * userspace, or the hypervisor performing a local exception
> > >  	 * return. No need to save/restore registers, no need to
> > > -	 * switch S2 MMU. Just do the canonical ERET.
> > > -	 *
> > > -	 * Unless the trap has to be forwarded further down the line,
> > > -	 * of course...
> > > +	 * switch S2 MMU. Just do the canonical ERET unlesss we are in
> > > +	 * nested context.
> > >  	 */
> > 
> > typo: unless
> > 
> > I feel like it wouldn't hurt to add a bit more detail to the comment
> > here, that L0 KVM doesn't use ERET traps in the nested context.
> > Otherwise it isn't clear why these always belong to the L1.
> 
> We already have a tiny bit of information in kvm_handle_eret(), but
> that's obviously a bit far down the line. Something like this?
> 
> diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c
> index a83be345f8450..684cebf23aa0e 100644
> --- a/arch/arm64/kvm/hyp/vhe/switch.c
> +++ b/arch/arm64/kvm/hyp/vhe/switch.c
> @@ -344,8 +344,13 @@ static bool kvm_hyp_handle_eret(struct kvm_vcpu *vcpu, u64 *exit_code)
>  	 * if this is a VHE guest hypervisor returning to its own
>  	 * userspace, or the hypervisor performing a local exception
>  	 * return. No need to save/restore registers, no need to
> -	 * switch S2 MMU. Just do the canonical ERET unlesss we are in
> +	 * switch S2 MMU. Just do the canonical ERET unless we are in
>  	 * nested context.
> +	 *
> +	 * Note that this is made possible because KVM itself never traps
> +	 * ERET when running an L2. The consequence is that any ERET trap is
> +	 * the result of HCR_EL2 or HFGITR_EL2 programming by L1 for its own
> +	 * guest, and the exception must be forwarded to L1.
>  	 */
>  	if (is_nested_ctxt(vcpu))
>  		return false;

Works for me!

Thanks,
Oliver