| Message ID | 20200424172416.243870-4-pbonzini@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | KVM: Event fixes and cleanup | expand |
Paolo Bonzini <pbonzini@redhat.com> writes: > We can immediately leave SVM guest mode in svm_check_nested_events > now that we have the nested_run_pending mechanism. This makes > things easier because we can run the rest of inject_pending_event > with GIF=0, and KVM will naturally end up requesting the next > interrupt window. > > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> > --- > arch/x86/kvm/svm/nested.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c > index e69e60ac1370..266fde240493 100644 > --- a/arch/x86/kvm/svm/nested.c > +++ b/arch/x86/kvm/svm/nested.c > @@ -778,13 +778,13 @@ int nested_svm_check_exception(struct vcpu_svm *svm, unsigned nr, > > static void nested_svm_intr(struct vcpu_svm *svm) > { > + trace_kvm_nested_intr_vmexit(svm->vmcb->save.rip); > + > svm->vmcb->control.exit_code = SVM_EXIT_INTR; > svm->vmcb->control.exit_info_1 = 0; > svm->vmcb->control.exit_info_2 = 0; > > - /* nested_svm_vmexit this gets called afterwards from handle_exit */ > - svm->nested.exit_required = true; > - trace_kvm_nested_intr_vmexit(svm->vmcb->save.rip); > + nested_svm_vmexit(svm); > } > > static bool nested_exit_on_intr(struct vcpu_svm *svm) Sorry for reporting this late but I just found out that this commit breaks Hyper-V 2016 on KVM on SVM completely (always hangs on boot). I haven't investigated it yet (well, this is Windows, you know...) but what's usually different about Hyper-V is that unlike KVM/Linux it has handlers for some hardware interrupts in the guest and not in the hypervisor.
On 21/05/20 14:50, Vitaly Kuznetsov wrote: > Sorry for reporting this late but I just found out that this commit > breaks Hyper-V 2016 on KVM on SVM completely (always hangs on boot). I > haven't investigated it yet (well, this is Windows, you know...) but > what's usually different about Hyper-V is that unlike KVM/Linux it has > handlers for some hardware interrupts in the guest and not in the > hypervisor. "Always hangs on boot" is easy. :) At this point I think it's easiest to debug it on top of the whole pending SVM patches that remove exit_required completely (and exit_required is not coming back anyway). Can you get a trace and send it to me? Paolo
On 21/05/20 16:08, Paolo Bonzini wrote: > On 21/05/20 14:50, Vitaly Kuznetsov wrote: >> Sorry for reporting this late but I just found out that this commit >> breaks Hyper-V 2016 on KVM on SVM completely (always hangs on boot). I >> haven't investigated it yet (well, this is Windows, you know...) but >> what's usually different about Hyper-V is that unlike KVM/Linux it has >> handlers for some hardware interrupts in the guest and not in the >> hypervisor. > > "Always hangs on boot" is easy. :) At this point I think it's easiest > to debug it on top of the whole pending SVM patches that remove > exit_required completely (and exit_required is not coming back anyway). Ok so there could be two bugs, as the hang seems to happens much earlier later in the series (try "grep int_ctl:.0x.....1.." on the trace). As one could guess from the grep, one thing that is certainly different between KVM and Hyper-V is that Hyper-V injects interrupts using int_ctl; sometimes it also uses eventinj but presumably it's just copying it from exitintinfo). This could cause problems: for example, when L1 wants to inject a virtual interrupt into L2 that has interrupts disabled or V_TPR >= V_INTR_PRIO, and KVM also wants to inject an interrupt to L1, then KVM might end up stomping on Hyper-V's int_ctl. However I cannot think off-hand of a scenario where this could happen in this case, because Hyper-V does set EXIT_INTR and therefore we should never get into enable_irq_window while L2 is running. Still, that's one place where I'd start adding some trace_printk's. Also, if a uniprocessor guest also fails, it might be easier to debug. Paolo
diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c index e69e60ac1370..266fde240493 100644 --- a/arch/x86/kvm/svm/nested.c +++ b/arch/x86/kvm/svm/nested.c @@ -778,13 +778,13 @@ int nested_svm_check_exception(struct vcpu_svm *svm, unsigned nr, static void nested_svm_intr(struct vcpu_svm *svm) { + trace_kvm_nested_intr_vmexit(svm->vmcb->save.rip); + svm->vmcb->control.exit_code = SVM_EXIT_INTR; svm->vmcb->control.exit_info_1 = 0; svm->vmcb->control.exit_info_2 = 0; - /* nested_svm_vmexit this gets called afterwards from handle_exit */ - svm->nested.exit_required = true; - trace_kvm_nested_intr_vmexit(svm->vmcb->save.rip); + nested_svm_vmexit(svm); } static bool nested_exit_on_intr(struct vcpu_svm *svm)
We can immediately leave SVM guest mode in svm_check_nested_events now that we have the nested_run_pending mechanism. This makes things easier because we can run the rest of inject_pending_event with GIF=0, and KVM will naturally end up requesting the next interrupt window. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> --- arch/x86/kvm/svm/nested.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)