Re: [PATCH] KVM: VMX: Fall back to IRR scan when PIR is empty despite PID.ON being set

[Chao Gao <chao.gao@intel.com>]

On Tue, Apr 28, 2026 at 03:03:26PM +0800, Chenyi Qiang wrote:
>Fall back to kvm_lapic_find_highest_irr() in vmx_sync_pir_to_irr() when
>PID.ON is set but PIR turns out to be empty, to correctly report the
>highest pending interrupt from the existing IRR.
>
>In a nested VM stress test, the following WARNING fires in
>vmx_check_nested_events() when kvm_cpu_has_interrupt() reports a pending
>interrupt but the subsequent kvm_apic_has_interrupt() (which invokes
>vmx_sync_pir_to_irr() again) returns -1:
>
>  WARNING: CPU: 99 PID: 57767 at arch/x86/kvm/vmx/nested.c:4449 vmx_check_nested_events+0x6bf/0x6e0 [kvm_intel]
>  Call Trace:
>   kvm_check_and_inject_events
>   vcpu_enter_guest.constprop.0
>   vcpu_run
>   kvm_arch_vcpu_ioctl_run
>   kvm_vcpu_ioctl
>   __x64_sys_ioctl
>   do_syscall_64
>   entry_SYSCALL_64_after_hwframe
>
>The root cause is a race between vmx_sync_pir_to_irr() on the target vCPU
>and __vmx_deliver_posted_interrupt() on a sender vCPU.  The sender
>performs two individually-atomic operations that are not a single
>transaction:
>
>  1. pi_test_and_set_pir(vector)  -- sets the PIR bit
>  2. pi_test_and_set_on()         -- sets PID.ON
>
>The following interleaving triggers the bug:
>
>  Sender vCPU (IPI):              Target vCPU (1st sync_pir_to_irr):
>  B1: set PIR[vector]
>                                  A1: pi_clear_on()
>                                  A2: pi_harvest_pir() -> sees B1 bit
>                                  A3: xchg() -> consumes bit, PIR=0
>                                      (1st sync returns correct max_irr)
>  B2: set PID.ON = 1
>
>                                  Target vCPU (2nd sync_pir_to_irr):
>                                  C1: pi_test_on() -> TRUE (from B2)
>                                  C2: pi_clear_on() -> ON=0
>                                  C3: pi_harvest_pir() -> PIR empty
>                                  C4: *max_irr = -1, early return
>                                      IRR NOT SCANNED
>
>The interrupt is not lost (it resides in the IRR from the first sync and
>is recovered on the next vcpu_enter_guest() iteration), but the incorrect
>max_irr causes a spurious WARNING and a wasted L2 VM-Enter/VM-Exit cycle.
>
>Fixes: b41f8638b9d3 ("KVM: VMX: Isolate pure loads from atomic XCHG when processing PIR")

Just FYI, I asked Copilot to review commit b41f8638b9d3, and it indeed
identified this subtle functional change:

"
Found 1 regression. In arch/x86/kvm/lapic.c::__kvm_apic_update_irr(), the new if
(!pending) return false; drops the old behavior of recomputing *max_irr from
APIC_IRR on an empty-PIR path. vmx_sync_pir_to_irr() still calls this helper
whenever PID.ON is set and then unconditionally passes max_irr to vmx_set_rvi(),
so when hardware has already drained PIR into vIRR/APIC_IRR, max_irr stays -1 and
KVM clears RVI despite an interrupt still being pending
"