Re: [PATCH 3/7] KVM: PPC: Explicitly force IPIs when directly kicking vCPUs
flat view
From: Gautam Menghani <hidden>
Date: 2026-10-30 14:49:26
Also in:
kvm, kvm-riscv, kvmarm, linux-arm-kernel, linux-mips, linux-riscv, lkml, loongarch
On Wed, Oct 28, 2026 at 12:02:55PM -0700, Sean Christopherson wrote:
quoted hunk ↗ jump to hunk
Explicitly force an IPI when invoking kvm_vcpu_kick() directly instead of relying on kvm_arch_vcpu_should_kick() to unconditionally return 1/true. This will allow dropping kvm_arch_vcpu_should_kick() in favor of kvm_request_needs_ipi(). No functional change intended (1 || 1 == true). Signed-off-by: Sean Christopherson <seanjc@google.com> --- arch/powerpc/include/asm/kvm_ppc.h | 13 ++++++++++++- arch/powerpc/kvm/book3s.c | 4 ++-- arch/powerpc/kvm/book3s_pr.c | 2 +- arch/powerpc/kvm/booke.c | 6 +++--- arch/powerpc/kvm/e500_emulate.c | 2 +- arch/powerpc/kvm/powerpc.c | 2 +- 6 files changed, 20 insertions(+), 9 deletions(-)diff --git a/arch/powerpc/include/asm/kvm_ppc.h b/arch/powerpc/include/asm/kvm_ppc.h index 169ea6a7fbad..bbe7378ad0ef 100644 --- a/arch/powerpc/include/asm/kvm_ppc.h +++ b/arch/powerpc/include/asm/kvm_ppc.h@@ -30,6 +30,17 @@ #endif #include <asm/inst.h> +/* + * TODO: For unknown reasons, KVM PPC has historically ignored vcpu->mode when + * determining if kicking a vCPU needs an IPI. Either document why that + * behavior is necessary, or drop this helper and the @force param from + * __kvm_vcpu_kick(). + */ +static inline void kvmppc_vcpu_kick(struct kvm_vcpu *vcpu) +{ + __kvm_vcpu_kick(vcpu, false, true); +} +
AFAICS, there is no reason for PPC to always return 1. I was looking at the old patches on mailing list and found this - https://lore.kernel.org/kvm/0FEE585F-5E21-47F2-A3F0-AD0DE05EBB43@suse.de (local)
How about we return 1 for kvm_arch_vcpu_in_guest_mode() on !x86 always, just like it's done today basically? Then we can
worry about needless IPIs later and don't regress from the respective current kick implementations.
However, I'll do some testing and get back by mid next week to make sure
there are no suprises.
Thanks,
Gautam