Re: [PATCH v4] KVM: PPC: Book3S HV: Avoid spurious interrupts caused by LPCR_MER bit

[Gautam Menghani]

On Fri, Oct 30, 2026 at 08:48:15PM +0530, Ritesh Harjani wrote:
> Gautam Menghani <gautam@xxxxxxxxxxxxx> writes:
> 
> > A huge number of spurious interrupts can be seen immediately after a KVM
> > on PowerNV guest boots up in XIVE mode.
> >
> > $ cat /proc/interrupts  | grep SPU
> > SPU:     223705     192439     273526     147623   Spurious interrupts
> >
> > This bug was introduced by commit ecd10702baae5 ("KVM: PPC: Book3S HV:
> > Handle pending exceptions on guest entry with MSR_EE"). The root cause
> > is that once LPCR_MER bit is set, it is supposed to be reset by
> > software. But when a vCPU starts running with LPCR_MER set, the vCPU does
> > not exit back to the host until the decrementer expires or there is an
> > hcall, etc. This is because KVM on PowerNV guests have support for
> > native XIVE, so they are not dependent on host for interrupt emulation.
> > Due to this behaviour, a huge number of spurious interrupts are seen
> > since LPCR_MER continues to be set and LPCR_MER cannot be reset until the
> > vCPU exits to the host.
> >
> > Fix this behaviour by not using the LPCR_MER bit whenever native XIVE is
> > available (currently in case of KVM on PowerNV only), as the XIVE hardware
> > can present interrupts to the KVM guest vCPU directly. So the LPCR_MER
> > functionality is not required. This reduces the number of spurious
> > interrupts drastically.
> >
> 
> Make sense. 
> 
> > Fixes: ecd10702baae5 ("KVM: PPC: Book3S HV: Handle pending exceptions on guest entry with MSR_EE")
> > Cc: stable@xxxxxxxxxxxxxxx # 6.8+
> > Reported-by: Timothy Pearson <tpearson@xxxxxxxxxxxxxxxxxxxxx>
> > Closes: https://lore.kernel.org/linuxppc-dev/582904882.11159.1786719390349.JavaMail.zimbra@xxxxxxxxxxxxxxxxxxxxxxxx
> > Signed-off-by: Gautam Menghani <gautam@xxxxxxxxxxxxx>
> 
> 
> > ---
> > v4:
> > 1. If interrupt mode is changed to XICS during guest reboot, MER should
> > be used. (Amit)
> >
> > v3:
> > 1. Continue the use of LPCR_MER when kernel-irqchip=off (Sashiko)
> >
> > v2:
> > 1. Handle the case where xive_interrupt_pending() is true and also the
> > external exception bit is set. (Narayana)
> >
> >  arch/powerpc/include/asm/kvm_ppc.h | 7 +++++++
> >  arch/powerpc/kvm/book3s_hv.c       | 2 +-
> >  2 files changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/powerpc/include/asm/kvm_ppc.h b/arch/powerpc/include/asm/kvm_ppc.h
> > index 169ea6a7fbad..9178406dc365 100644
> > --- a/arch/powerpc/include/asm/kvm_ppc.h
> > +++ b/arch/powerpc/include/asm/kvm_ppc.h
> > @@ -747,6 +747,11 @@ static inline int kvmppc_xive_enabled(struct kvm_vcpu *vcpu)
> >  	return vcpu->arch.irq_type == KVMPPC_IRQ_XIVE;
> >  }
> >  
> > +static inline bool kvmppc_xive_native_enabled(struct kvm_vcpu *vcpu)
> > +{
> > +	return kvmppc_xive_enabled(vcpu) && vcpu->kvm->arch.xive_devices.native;
> 
> I was checking the code and I am not sure whether we need to also check
> for "vcpu->kvm->arch.xive_devices.native"?
> 
> Can you explain why do we need to check for xive_devices.native pointer
> to be non-NULL? Because if we don't need this then it simplifies the
> code as we can directly use kvmppc_xive_enabled(vcpu) helper.

Yes you are right. I wrongly assumed that kvmppc_xive_enabled() returns
true when kernel-irqchip=off. I was printing the logs for
vcpu->arch.irq_type for every scenario and I guess I must have looked at
the wrong logs when I wrote this solution. Will send a v5.

Thanks.