On Fri, Apr 09, 2021, Lai Jiangshan wrote:
On Fri, Nov 27, 2020 at 7:26 PM Paolo Bonzini pbonzini@redhat.com wrote:
kvm_cpu_accept_dm_intr and kvm_vcpu_ready_for_interrupt_injection are a hodge-podge of conditions, hacked together to get something that more or less works. But what is actually needed is much simpler; in both cases the fundamental question is, do we have a place to stash an interrupt if userspace does KVM_INTERRUPT?
In userspace irqchip mode, that is !vcpu->arch.interrupt.injected. Currently kvm_event_needs_reinjection(vcpu) covers it, but it is unnecessarily restrictive.
In split irqchip mode it's a bit more complicated, we need to check kvm_apic_accept_pic_intr(vcpu) (the IRQ window exit is basically an INTACK cycle and thus requires ExtINTs not to be masked) as well as !pending_userspace_extint(vcpu). However, there is no need to check kvm_event_needs_reinjection(vcpu), since split irqchip keeps pending ExtINT state separate from event injection state, and checking kvm_cpu_has_interrupt(vcpu) is wrong too since ExtINT has higher priority than APIC interrupts. In fact the latter fixes a bug: when userspace requests an IRQ window vmexit, an interrupt in the local APIC can cause kvm_cpu_has_interrupt() to be true and thus kvm_vcpu_ready_for_interrupt_injection() to return false. When this happens, vcpu_run does not exit to userspace but the interrupt window vmexits keep occurring. The VM loops without any hope of making progress.
Once we try to fix these with something like
return kvm_arch_interrupt_allowed(vcpu) &&
!kvm_cpu_has_interrupt(vcpu) &&!kvm_event_needs_reinjection(vcpu) &&kvm_cpu_accept_dm_intr(vcpu);
(!lapic_in_kernel(vcpu)? !vcpu->arch.interrupt.injected: (kvm_apic_accept_pic_intr(vcpu)&& !pending_userspace_extint(v)));we realize two things. First, thanks to the previous patch the complex conditional can reuse !kvm_cpu_has_extint(vcpu). Second, the interrupt window request in vcpu_enter_guest()
bool req_int_win = dm_request_for_irq_injection(vcpu) && kvm_cpu_accept_dm_intr(vcpu);should be kept in sync with kvm_vcpu_ready_for_interrupt_injection(): it is unnecessary to ask the processor for an interrupt window if we would not be able to return to userspace. Therefore, the complex conditional is really the correct implementation of kvm_cpu_accept_dm_intr(vcpu). It all makes sense:
- we can accept an interrupt from userspace if there is a place to stash it (and, for irqchip split, ExtINTs are not masked). Interrupts from userspace _can_ be accepted even if right now EFLAGS.IF=0.
Hello, Paolo
If userspace does KVM_INTERRUPT, vcpu->arch.interrupt.injected is set immediately, and in inject_pending_event(), we have
else if (!vcpu->arch.exception.pending) { if (vcpu->arch.nmi_injected) { kvm_x86_ops.set_nmi(vcpu); can_inject = false; } else if (vcpu->arch.interrupt.injected) { kvm_x86_ops.set_irq(vcpu); can_inject = false; } }I'm curious about that can the kvm_x86_ops.set_irq() here be possible to queue the irq with EFLAGS.IF=0? If not, which code prevents it?
The interrupt is only directly injected if the local APIC is _not_ in-kernel. If userspace is managing the local APIC, my understanding is that userspace is also responsible for honoring EFLAGS.IF, though KVM aids userspace by updating vcpu->run->ready_for_interrupt_injection when exiting to userspace. When userspace is modeling the local APIC, that resolves to kvm_vcpu_ready_for_interrupt_injection():
return kvm_arch_interrupt_allowed(vcpu) && kvm_cpu_accept_dm_intr(vcpu);
where kvm_arch_interrupt_allowed() checks EFLAGS.IF (and an edge case related to nested virtualization). KVM also captures EFLAGS.IF in vcpu->run->if_flag. For whatever reason, QEMU checks both vcpu->run flags before injecting an IRQ, maybe to handle a case where QEMU itself clears EFLAGS.IF?
I'm asking about this because I just noticed that interrupt can be queued when exception pending, and this patch relaxed it even more.
Note: interrupt can NOT be queued when exception pending until 664f8e26b00c7 ("KVM: X86: Fix loss of exception which has not yet been injected") which I think is dangerous.