Re: [PATCH v3] KVM: nVMX: Fix attempting to emulate "Acknowledge interrupt on exit" when there is no interrupt which L1 requires to inject to L2
From: Radim KrÄmÃÅ
Date: Thu Aug 03 2017 - 08:30:29 EST
2017-08-03 07:01+0800, Wanpeng Li:
> 2017-08-03 4:26 GMT+08:00 Radim KrÄmÃÅ <rkrcmar@xxxxxxxxxx>:
> > 2017-08-02 03:48-0700, Wanpeng Li:
> >> From: Wanpeng Li <wanpeng.li@xxxxxxxxxxx>
> >> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> >> @@ -10761,7 +10761,8 @@ static int vmx_check_nested_events(struct kvm_vcpu *vcpu, bool external_intr)
> >> return 0;
> >> }
> >> - if ((kvm_cpu_has_interrupt(vcpu) || external_intr) &&
> >> + if ((kvm_cpu_has_interrupt(vcpu) ||
> >> + (external_intr && !nested_exit_intr_ack_set(vcpu))) &&
> > I think it would be safer to also add something like the second hunk I
> > posted (that also takes nested_exit_on_intr() into account).
> > The issue is that we're allowing L2's GUEST_RFLAGS and
> > GUEST_INTERRUPTIBILITY_INFO to disable userspace interrupt injection
> > even though neither affect delivery of interrupts into L1.
> > This means that L2 can block/postpone the delivery to L1 by doing "cli;
> > busy_loop/normal_critical_section".
> Ouch! My fault, the v3 patch w/o the second hunk and w/ the second
> hunk both can result in L1 guest softlockup. I just tested the patch
> with L2 windows guest yesterday, however, the softlockup can happen
> when the L2 is the linux guest. So should we still take the v2 for the
Sure, that one is an improvement over the current situation (I guess it
doesn't break any hypervisor).
I'll just add a comment about its incorrectness.