mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH] KVM: PPC: Book3S HV: Avoid triggering an extra interrupt for a vCPU
@ 2026-09-15  6:01 Gautam Menghani
  2026-09-15  8:38 ` Narayana Murty N
  0 siblings, 1 reply; 3+ messages in thread
From: Gautam Menghani @ 2026-09-15  6:01 UTC (permalink / raw)
  To: maddy, npiggin, mpe, chleroy, tpearson
  Cc: Gautam Menghani, linuxppc-dev, kvm, linux-kernel, stable

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.

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
Signed-off-by: Gautam Menghani <gautam@linux.ibm.com>
---
 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);
-		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
-- 
2.55.0


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] KVM: PPC: Book3S HV: Avoid triggering an extra interrupt for a vCPU
  2026-09-15  6:01 [PATCH] KVM: PPC: Book3S HV: Avoid triggering an extra interrupt for a vCPU Gautam Menghani
@ 2026-09-15  8:38 ` Narayana Murty N
  2026-09-15  9:38   ` Gautam Menghani
  0 siblings, 1 reply; 3+ messages in thread
From: Narayana Murty N @ 2026-09-15  8:38 UTC (permalink / raw)
  To: Gautam Menghani, maddy, npiggin, mpe, chleroy, tpearson
  Cc: linuxppc-dev, kvm, linux-kernel, stable

Hi Gautam,

On 15/09/26 11:31 AM, Gautam Menghani wrote:
> 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.
> 
> 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
> Signed-off-by: Gautam Menghani <gautam@linux.ibm.com>
> ---
>   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:
> -		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.

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.

Thanks,
Narayana Murty N

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] KVM: PPC: Book3S HV: Avoid triggering an extra interrupt for a vCPU
  2026-09-15  8:38 ` Narayana Murty N
@ 2026-09-15  9:38   ` Gautam Menghani
  0 siblings, 0 replies; 3+ messages in thread
From: Gautam Menghani @ 2026-09-15  9:38 UTC (permalink / raw)
  To: Narayana Murty N
  Cc: maddy, npiggin, mpe, chleroy, tpearson, linuxppc-dev, kvm,
	linux-kernel, stable

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:
> > 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.
> > 
> > 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
> > Signed-off-by: Gautam Menghani <gautam@linux.ibm.com>
> > ---
> >   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:
> > -		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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2026-09-15  9:39 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-09-15  6:01 [PATCH] KVM: PPC: Book3S HV: Avoid triggering an extra interrupt for a vCPU Gautam Menghani
2026-09-15  8:38 ` Narayana Murty N
2026-09-15  9:38   ` Gautam Menghani

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®