Hi Eric,
On Thu, 10 Aug 2023 09:35:41 +0100,
Eric Auger <eric.auger@xxxxxxxxxx> wrote:
>
> Hi Marc,
>
> On 8/8/23 13:47, Marc Zyngier wrote:
> > HFGITR_EL2 allows the trap of SVC instructions to EL2. Allow these
> > traps to be forwarded. Take this opportunity to deny any 32bit activity
> > when NV is enabled.
>
> I can't figure out how HFGITR_EL2.{SVC_EL1, SVC_EL0 and ERET} are
> handled. Please could you explain.
- SVC: KVM itself never traps it, so any trap of SVC must be the
result of a guest trap -- we don't need to do any demultiplexing. We
thus directly inject the trap back. This is what the comment in
handle_svc() tries to capture, but obviously fails to convey the
point.
- ERET: This is already handled since 6898a55ce38c ("KVM: arm64: nv:
Handle trapped ERET from virtual EL2"). Similarly to SVC, KVM never
traps it unless we run NV.
Now, looking into it, I think I'm missing the additional case where
the L2 guest runs at vEL1. I'm about to add the following patchlet:
diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
index 3b86d534b995..617ae6dea5d5 100644
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@ -222,7 +222,22 @@ static int kvm_handle_eret(struct kvm_vcpu *vcpu)
if (kvm_vcpu_get_esr(vcpu) & ESR_ELx_ERET_ISS_ERET)
return kvm_handle_ptrauth(vcpu);
- kvm_emulate_nested_eret(vcpu);
+ /*
+ * If we got here, two possibilities:
+ *
+ * - the guest is in EL2, and we need to fully emulate ERET
+ *
+ * - the guest is in EL1, and we need to reinject the
+ * exception into the L1 hypervisor.
+ *
+ * If KVM ever traps ERET for its own use, we'll have to
+ * revisit this.
+ */
+ if (is_hyp_ctxt(vcpu))
+ kvm_emulate_nested_eret(vcpu);
+ else
+ kvm_inject_nested_sync(vcpu, kvm_vcpu_get_esr(vcpu));
+
return 1;
}
Does the above help?
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
