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

[sashiko-bot@kernel.org]

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?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260918055848.28390-1-gautam@linux.ibm.com?part=1