Re: [PATCH] KVM: PPC: Book3S HV: Avoid triggering an extra interrupt for a vCPU

On Tue, Sep 15, 2026 at 02:08:28PM +0530, Narayana Murty N wrote:

Hi Gautam,

On 15/09/26 11:31 AM, Gautam Menghani wrote:

quoted

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 when there is an interrupt pending for a vCPU
(xive_interrupt_pending() returns true) and MSR_EE is disabled for the
vCPU, LPCR_MER ends up getting set for the VCPU. When the vCPU starts
running, the XIVE hardware presents the pending interrupt to the vCPU
(since the KVM guest has native XIVE support) and then a second spurious
interrupt gets presented to the vCPU due to the LPCR_MER bit being set.

I agree that we should avoid setting LPCR_MER when the pending interrupt
will already be delivered natively by XIVE on PowerNV.

quoted

Fix this behaviour by not queuing up any extra interrupts with LPCR_MER
if there is an interrupt already pending in the case of KVM on PowerNV.
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 (local)
Signed-off-by: Gautam Menghani <redacted>
---
  arch/powerpc/kvm/book3s_hv.c | 5 ++---
  1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 7667563fb9ff..fda3767ebc9e 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c

@@ -4937,9 +4937,8 @@ int kvmhv_run_single_vcpu(struct kvm_vcpu *vcpu, u64 time_limit,
  	if (!nested) {
  		kvmppc_core_prepare_to_enter(vcpu);

The current code handles two different indications of an external interrupt:

quoted

-		if (test_bit(BOOK3S_IRQPRIO_EXTERNAL,
-			     &vcpu->arch.pending_exceptions) ||
-		    xive_interrupt_pending(vcpu)) {
+		if (!xive_interrupt_pending(vcpu) && test_bit(BOOK3S_IRQPRIO_EXTERNAL,
+							      &vcpu->arch.pending_exceptions)) {
  			/*
  			 * For nested HV, don't synthesize but always pass MER,
  			 * the L0 will be able to optimise that more

This means xive_interrupt_pending() now gates the entire block, including
the BOOK3S_IRQPRIO_EXTERNAL handling, rather than only avoiding the LPCR_MER
which causes the duplicate interrupt.

Yes valid point. If both conditions are true, we'll never get inside the
if block, which is undesirable. I'll fix this in v2.

Also, the changelog describes the issue as specific to KVM on PowerNV, while
this condition also affects the pSeries/nested handling in the same block.

No, xive_interrupt_pending() always returns false for KVM on Pseries. So
effectively, we end up only checking for the BOOK3S_IRQPRIO_EXTERNAL
bit. So this is not a problem for KVM on LPAR / nested guests on
PowerNV.

Thanks,
Narayana Murty N