On Fri, Sep 18, 2009 at 03:00:32PM +0200, Alexander Graf wrote:
> Normally when event_inj is valid the host CPU would write the contents to
> exit_int_info, so the hypervisor knows that the event wasn't injected.
>
> We failed to do so so far, so let's model closer to the CPU.
>
> Signed-off-by: Alexander Graf <agraf@xxxxxxx>
Acked-by: Joerg Roedel <joerg.roedel@xxxxxxx>
The commit-message does not state this explicitly, but this patch fixes
a real bug with lost interrupts in nested svm.
> ---
> arch/x86/kvm/svm.c | 16 ++++++++++++++++
> 1 files changed, 16 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> index 12ec8ee..75e3d75 100644
> --- a/arch/x86/kvm/svm.c
> +++ b/arch/x86/kvm/svm.c
> @@ -1643,6 +1643,22 @@ static int nested_svm_vmexit(struct vcpu_svm *svm)
> nested_vmcb->control.exit_info_2 = vmcb->control.exit_info_2;
> nested_vmcb->control.exit_int_info = vmcb->control.exit_int_info;
> nested_vmcb->control.exit_int_info_err = vmcb->control.exit_int_info_err;
> +
> + /*
> + * If we emulate a VMRUN/#VMEXIT in the same host #vmexit cycle we have
> + * to make sure that we do not lose injected events. So check event_inj
> + * here and copy it to exit_int_info if it is valid.
> + * exit_int_info and event_inj can't be both valid because the below
> + * case only happens on a VMRUN instruction intercept which has not
> + * valid exit_int_info set.
> + */
> + if (vmcb->control.event_inj & SVM_EVTINJ_VALID) {
> + struct vmcb_control_area *nc = &nested_vmcb->control;
> +
> + nc->exit_int_info = vmcb->control.event_inj;
> + nc->exit_int_info_err = vmcb->control.event_inj_err;
> + }
> +
> nested_vmcb->control.tlb_ctl = 0;
> nested_vmcb->control.event_inj = 0;
> nested_vmcb->control.event_inj_err = 0;
> --
> 1.6.0.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
