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 > moment? 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.
