On Fri, Sep 18, 2026 at 06:08:29AM +0000, [email protected] 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 <[email protected]> > > 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.zim...@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
