KVM: x86: Unconditionally set irr_pending when updating APICv state
Always set irr_pending (to true) when updating APICv status to fix a bug where KVM fails to set irr_pending when userspace sets APIC state and APICv is disabled, which ultimate results in KVM failing to inject the pending interrupt(s) that userspace stuffed into the vIRR, until another interrupt happens to be emulated by KVM. Only the APICv-disabled case is flawed, as KVM forces apic->irr_pending to be true if APICv is enabled, because not all vIRR updates will be visible to KVM. Hit the bug with a big hammer, even though strictly speaking KVM can scan the vIRR and set/clear irr_pending as appropriate for this specific case. The bug was introduced by commit755c2bf878
("KVM: x86: lapic: don't touch irr_pending in kvm_apic_update_apicv when inhibiting it"), which as the shortlog suggests, deleted code that updated irr_pending. Before that commit, kvm_apic_update_apicv() did indeed scan the vIRR, with with the crucial difference that kvm_apic_update_apicv() did the scan even when APICv was being *disabled*, e.g. due to an AVIC inhibition. struct kvm_lapic *apic = vcpu->arch.apic; if (vcpu->arch.apicv_active) { /* irr_pending is always true when apicv is activated. */ apic->irr_pending = true; apic->isr_count = 1; } else { apic->irr_pending = (apic_search_irr(apic) != -1); apic->isr_count = count_vectors(apic->regs + APIC_ISR); } And _that_ bug (clearing irr_pending) was introduced by commitb26a695a1d
("kvm: lapic: Introduce APICv update helper function"), prior to which KVM unconditionally set irr_pending to true in kvm_apic_set_state(), i.e. assumed that the new virtual APIC state could have a pending IRQ. Furthermore, in addition to introducing this issue, commit755c2bf878
also papered over the underlying bug: KVM doesn't ensure CPUs and devices see APICv as disabled prior to searching the IRR. Waiting until KVM emulates an EOI to update irr_pending "works", but only because KVM won't emulate EOI until after refresh_apicv_exec_ctrl(), and there are plenty of memory barriers in between. I.e. leaving irr_pending set is basically hacking around bad ordering. So, effectively revert to the pre-b26a695a1d78 behavior for state restore, even though it's sub-optimal if no IRQs are pending, in order to provide a minimal fix, but leave behind a FIXME to document the ugliness. With luck, the ordering issue will be fixed and the mess will be cleaned up in the not-too-distant future. Fixes:755c2bf878
("KVM: x86: lapic: don't touch irr_pending in kvm_apic_update_apicv when inhibiting it") Cc: stable@vger.kernel.org Cc: Maxim Levitsky <mlevitsk@redhat.com> Reported-by: Yong He <zhuangel570@gmail.com> Closes: https://lkml.kernel.org/r/20241023124527.1092810-1-alexyonghe%40tencent.com Signed-off-by: Sean Christopherson <seanjc@google.com> Message-ID: <20241106015135.2462147-1-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This commit is contained in:
parent
e3a7792d96
commit
d3ddef46f2
@ -2629,19 +2629,26 @@ void kvm_apic_update_apicv(struct kvm_vcpu *vcpu)
|
|||||||
{
|
{
|
||||||
struct kvm_lapic *apic = vcpu->arch.apic;
|
struct kvm_lapic *apic = vcpu->arch.apic;
|
||||||
|
|
||||||
if (apic->apicv_active) {
|
|
||||||
/* irr_pending is always true when apicv is activated. */
|
|
||||||
apic->irr_pending = true;
|
|
||||||
apic->isr_count = 1;
|
|
||||||
} else {
|
|
||||||
/*
|
/*
|
||||||
* Don't clear irr_pending, searching the IRR can race with
|
* When APICv is enabled, KVM must always search the IRR for a pending
|
||||||
* updates from the CPU as APICv is still active from hardware's
|
* IRQ, as other vCPUs and devices can set IRR bits even if the vCPU
|
||||||
* perspective. The flag will be cleared as appropriate when
|
* isn't running. If APICv is disabled, KVM _should_ search the IRR
|
||||||
* KVM injects the interrupt.
|
* for a pending IRQ. But KVM currently doesn't ensure *all* hardware,
|
||||||
|
* e.g. CPUs and IOMMUs, has seen the change in state, i.e. searching
|
||||||
|
* the IRR at this time could race with IRQ delivery from hardware that
|
||||||
|
* still sees APICv as being enabled.
|
||||||
|
*
|
||||||
|
* FIXME: Ensure other vCPUs and devices observe the change in APICv
|
||||||
|
* state prior to updating KVM's metadata caches, so that KVM
|
||||||
|
* can safely search the IRR and set irr_pending accordingly.
|
||||||
*/
|
*/
|
||||||
|
apic->irr_pending = true;
|
||||||
|
|
||||||
|
if (apic->apicv_active)
|
||||||
|
apic->isr_count = 1;
|
||||||
|
else
|
||||||
apic->isr_count = count_vectors(apic->regs + APIC_ISR);
|
apic->isr_count = count_vectors(apic->regs + APIC_ISR);
|
||||||
}
|
|
||||||
apic->highest_isr_cache = -1;
|
apic->highest_isr_cache = -1;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user