On Mon, Sep 21, 2026 at 11:25:38AM +0000, [email protected] wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s)
> to consider:
> - [High] kvm: ppc: lost LPCR_MER interrupts for XICS due to XIVE state leak
> --
>
> commit 215dda3f95780a965ce67c9c452b6f7d1948e486
> Author: Gautam Menghani <[email protected]>
>
> KVM: PPC: Book3S HV: Avoid spurious interrupts caused by LPCR_MER bit
>
> This commit avoids spurious interrupts for KVM on PowerNV guests by not
> setting the LPCR_MER bit when native XIVE is available. It introduces a new
> helper, kvmppc_xive_native_enabled(), to check for native XIVE and skips
> setting LPCR_MER if it evaluates to true.
>
> Closes:
> https://lore.kernel.org/linuxppc-dev/582904882.11159.1786719390349.javamail.zim...@raptorengineeringinc.com
>
> > diff --git a/arch/powerpc/include/asm/kvm_ppc.h
> > b/arch/powerpc/include/asm/kvm_ppc.h
> > index 169ea6a7fbad4..580ad2548c2bf 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 *kvm)
> > +{
> > + return kvm->arch.xive_devices.native;
> > +}
> > +
>
> [ ... ]
>
> > diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> > index dbac3573b2c89..cb2bb29451a7f 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 (!kvmppc_xive_native_enabled(vcpu->kvm))
> > lpcr |= LPCR_MER;
> > } else {
> > /*
>
> [Severity: High]
> Does kvmppc_xive_native_enabled() accurately reflect whether XIVE is currently
> in use?
>
> If a VM switches from XIVE to XICS (such as during a kexec or CAS
> renegotiation), the XIVE native device is destroyed. However, the native
> pointer is intentionally not cleared:
The kexec case is not supported for guests - booting a KVM guest in XIVE mode
and
kexec to XICS mode.
>
> arch/powerpc/kvm/book3s_xive_native.c:kvmppc_xive_native_release() {
> ...
> /*
> * A reference of the kvmppc_xive pointer is now kept under
> * the xive_devices struct of the machine for reuse. It is
> * freed when the VM is destroyed for now until we fix all the
> * execution paths.
> */
>
> kfree(dev);
> }
>
> When running in XICS mode after this switch, kvmppc_xive_native_enabled()
> will continue to evaluate to true.
>
> Will this cause KVM to bypass setting LPCR_MER, and subsequently fail to
> inject external interrupts when MSR_EE=0, resulting in a guest hang?
No. If LPCR_MER is not set, the only effect of that is the vCPU will have to
exit to the host for the host to inject interrupts into the vCPU. One
extra exit isn't a big deal.
>
> Could this check instead evaluate the active vCPU IRQ routing, for example by
> using !kvmppc_xive_enabled(vcpu)?
kvmppc_xive_enabled() does not check for native/irqchip=on case. It
returns true even if emulation is used.
>
> --
> Sashiko AI review ยท
> https://sashiko.dev/#/patchset/[email protected]?part=1
