Re: [PATCH] KVM: x86: Ignore pending PV EOI if the vCPU has since disabled PV EOIs

[Sean Christopherson <seanjc@google.com>]

On Wed, Jun 24, 2026, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> > --- a/arch/x86/kvm/lapic.c
> > +++ b/arch/x86/kvm/lapic.c
> [ ... ]
> > @@ -3382,8 +3388,6 @@ static void apic_sync_pv_eoi_from_guest(struct kvm_vcpu *vcpu,
> >  	 * KVM_APIC_PV_EOI_PENDING is set, KVM_PV_EOI_ENABLED is unset:
> >  	 * 	-> host enabled PV EOI, guest executed EOI.
> >  	 */
> > -	BUG_ON(!pv_eoi_enabled(vcpu));
> > -
> >  	if (pv_eoi_test_and_clr_pending(vcpu))
> >  		return;
> >  	vector = apic_set_eoi(apic);
> 
> [Severity: High]
> This is a pre-existing issue, but if pv_eoi_test_and_clr_pending() encounters
> a memory access error, does it skip clearing the pending bit?

Yes, that's what this patch is fixing.

> Looking at pv_eoi_test_and_clr_pending():
> 
> arch/x86/kvm/lapic.c:pv_eoi_test_and_clr_pending() {
>     if (pv_eoi_get_user(vcpu, &val) < 0)
>         return false;
>     ...
>     __clear_bit(KVM_APIC_PV_EOI_PENDING, &vcpu->arch.apic_attention);
>     ...
> }
> 
> If a guest provides an invalid memory address, pv_eoi_test_and_clr_pending()
> returns false early without clearing KVM_APIC_PV_EOI_PENDING.
> 
> Will this cause apic_sync_pv_eoi_from_guest() to falsely assume the guest
> performed an EOI and proceed to call apic_set_eoi() below?
> 
> Since the pending bit remains set, will KVM continue calling apic_set_eoi()
> on every subsequent VM exit, erroneously clearing valid in-service interrupts
> and making the VM completely unresponsive?

Yes, but the alternative is to "falsely assume" the guest did NOT perform an EOI,
in which case in-service IRQs will never be cleared, and the guest be completely
unresponsive because it will stop receiving IRQs.

I.e. the problem isn't KVM's behavior, it's that the guest is hosed if the PV EOI
page goes missing.