Re: [PATCH v2 6.1.y 1/3] KVM: nVMX: Add a helper to get highest pending from Posted Interrupt vector

[Sean Christopherson <seanjc@google.com>]

On Fri, Jun 19, 2026, sashiko-bot@kernel.org wrote:
> > diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
> > index bdc462944cb08..7d8e18dbe8531 100644
> > --- a/arch/x86/kvm/vmx/nested.c
> > +++ b/arch/x86/kvm/vmx/nested.c
> [ ... ]
> > @@ -3818,8 +3819,8 @@ static int vmx_complete_nested_posted_interrupt(struct kvm_vcpu *vcpu)
> >  	if (!pi_test_and_clear_on(vmx->nested.pi_desc))
> >  		return 0;
> >  
> > -	max_irr = find_last_bit((unsigned long *)vmx->nested.pi_desc->pir, 256);
> > -	if (max_irr != 256) {
> > +	max_irr = pi_find_highest_vector(vmx->nested.pi_desc);
> > +	if (max_irr > 0) {
> 
> [Severity: Medium]
> Does this condition inadvertently skip vector 0?

No, it deliberately skips vector 0.

> The commit message states that pi_find_highest_vector() returns -1 to indicate
> no interrupt pending, so max_irr can be -1 or 0-255. By checking max_irr > 0,
> the code skips processing if vector 0 is the highest pending interrupt.
> 
> While vector 0 is an invalid APIC interrupt that hardware typically ignores,
> skipping it here means KVM does not call __kvm_apic_update_irr(). As a result,
> vector 0 could remain stuck in the PIR array instead of being cleared, which
> diverges from the lockless PIR/ON protocol.
> 
> Should this condition check for max_irr >= 0 or max_irr != -1 instead?

Nah, because vmcs.GUEST_INTR_STATUS's RVI will never satisfy:

  RVI[7:4] > VPPR[7:4]

and so the interrupt (that shouldn't/can't exist) will never be delivered, even
if the KVM check were "fixed".  If anything KVM could do "max_irr > 15", probably
with a #define of some kind instead of an open coded literally.

Regardless, that's something to tweak in upstream, not in LTS backports.