Got a question about this one, On Mon, Feb 26, 2024 at 10:05:55AM +0000, Marc Zyngier wrote: > If the L1 hypervisor decides to trap ERETs while running L2, > make sure we don't try to emulate it, just like we wouldn't > if it had its NV bit set. > > The exception will be reinjected from the core handler. > > Signed-off-by: Marc Zyngier <maz@xxxxxxxxxx> > --- > arch/arm64/kvm/hyp/vhe/switch.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c > index eaf242b8e0cf..3ea9bdf6b555 100644 > --- a/arch/arm64/kvm/hyp/vhe/switch.c > +++ b/arch/arm64/kvm/hyp/vhe/switch.c > @@ -220,7 +220,8 @@ static bool kvm_hyp_handle_eret(struct kvm_vcpu *vcpu, u64 *exit_code) > * Unless the trap has to be forwarded further down the line, > * of course... > */ > - if (__vcpu_sys_reg(vcpu, HCR_EL2) & HCR_NV) > + if ((__vcpu_sys_reg(vcpu, HCR_EL2) & HCR_NV) || > + (__vcpu_sys_reg(vcpu, HFGITR_EL2) & HFGITR_EL2_ERET)) > return false; > > spsr = read_sysreg_el1(SYS_SPSR); Are we missing a forward_traps() call in kvm_emulated_nested_eret() for the HFGITR case? Trying to follow the code path here, and I'm unsure of where else the HFIGTR_EL2_ERET trap would be forwarded: kvm_arm_vcpu_enter_exit -> ERET executes in guest fixup_guest_exit -> kvm_hyp_handle_eret (returns false) handle_exit -> kvm_handle_eret -> kvm_emulated_nested_eret if HCR_NV forward traps else emulate ERET And if the answer is that it is being reinjected somewhere, putting that function name in the commit instead of 'core handler' would help with understanding! I need to find the time to get an NV setup set-up, so I can do some experiments myself. Thanks, Joey
