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

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

[Gautam Menghani]

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 in case of KVM on
PowerNV, 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.

Fixes: ecd10702baae5 ("KVM: PPC: Book3S HV: Handle pending exceptions on guest entry with MSR_EE")
Cc: stable@vger.kernel.org #6.8+
Reported-by: Timothy Pearson <tpearson@raptorengineering.com>
Closes: https://lore.kernel.org/linuxppc-dev/582904882.11159.1786719390349.JavaMail.zimbra@raptorengineeringinc.com
Signed-off-by: Gautam Menghani <gautam@linux.ibm.com>
---
v2:
1. Handle the case where xive_interrupt_pending() is true and also the
external exception bit is set.

 arch/powerpc/kvm/book3s_hv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index dbac3573b2c8..f4d12a97311b 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -4980,7 +4980,7 @@ int kvmhv_run_single_vcpu(struct kvm_vcpu *vcpu, u64 time_limit,
 			if (!kvmhv_on_pseries() && (__kvmppc_get_msr_hv(vcpu) & MSR_EE))
 				kvmppc_inject_interrupt_hv(vcpu,
 							   BOOK3S_INTERRUPT_EXTERNAL, 0);
-			else
+			else if (!xics_on_xive())
 				lpcr |= LPCR_MER;
 		} else {
 			/*
-- 
2.55.0

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

[Gautam Menghani]

On Fri, Sep 18, 2026 at 06:08:29AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] kvm: ppc: software-injected external interrupts lost on XIVE hosts
> --
> 
> commit 05773d5b089dd4410c7e3e3a1611da5479c7d1a4
> Author: Gautam Menghani <gautam@linux.ibm.com>
> 
> KVM: PPC: Book3S HV: Avoid spurious interrupts caused by LPCR_MER bit
> 
> This commit aims to avoid a huge number of spurious interrupts on KVM PowerNV
> guests in XIVE mode by not using the LPCR_MER bit when the hardware can
> present interrupts directly. It modifies kvmhv_run_single_vcpu() to skip
> setting LPCR_MER when xics_on_xive() returns true.
> 
> Closes: https://lore.kernel.org/linuxppc-dev/582904882.11159.1786719390349.JavaMail.zimbra@raptorengineeringinc.com
> 
> > diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> > index dbac3573b2c89..f4d12a97311b9 100644
> > --- a/arch/powerpc/kvm/book3s_hv.c
> > +++ b/arch/powerpc/kvm/book3s_hv.c
> > @@ -4980,7 +4980,7 @@ int kvmhv_run_single_vcpu(struct kvm_vcpu *vcpu, u64 time_limit,
> >  			if (!kvmhv_on_pseries() && (__kvmppc_get_msr_hv(vcpu) & MSR_EE))
> >  				kvmppc_inject_interrupt_hv(vcpu,
> >  							   BOOK3S_INTERRUPT_EXTERNAL, 0);
> > -			else
> > +			else if (!xics_on_xive())
> >  				lpcr |= LPCR_MER;
> 
> [Severity: High]
> Does this unconditionally disable LPCR_MER on XIVE hosts, potentially dropping
> software-injected external interrupts when MSR_EE=0?
> 
> The outer condition in kvmhv_run_single_vcpu() checks if either a KVM software
> interrupt (BOOK3S_IRQPRIO_EXTERNAL) or a hardware XIVE interrupt is pending.
> 
> When MSR_EE=0 on guest entry, the patched code evaluates:
> 
>     else if (!xics_on_xive())
>         lpcr |= LPCR_MER;
> 
> Since xics_on_xive() evaluates to true globally on bare-metal POWER9+ hosts
> with XIVE enabled, regardless of whether the guest uses the in-kernel XIVE
> irqchip, bypassing LPCR_MER here seems to cause software-injected interrupts
> (such as those from userspace via the KVM_INTERRUPT ioctl) to lose the
> hardware trap mechanism that normally fires when the guest later sets
> MSR_EE=1.
> 
> Could this lead to dropped or severely delayed external interrupts for guests
> using a userspace irqchip?

Yes this is a valid case. When kernel irqchip is off, the guest vCPU will be required to make an extra
exit to the host for interrupt injection. Will fix this in v3.

Thanks,
Gautam