On Mon, Mar 24, 2025, Mingwei Zhang wrote:
> diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
> index 385e3a5fc304..18cd418fe106 100644
> --- a/arch/x86/kernel/irq.c
> +++ b/arch/x86/kernel/irq.c
> @@ -312,16 +312,22 @@ DEFINE_IDTENTRY_SYSVEC(sysvec_x86_platform_ipi)
> static void dummy_handler(void) {}
> static void (*kvm_posted_intr_wakeup_handler)(void) = dummy_handler;
>
> -void kvm_set_posted_intr_wakeup_handler(void (*handler)(void))
> +void x86_set_kvm_irq_handler(u8 vector, void (*handler)(void))
> {
> - if (handler)
> + if (!handler)
> + handler = dummy_handler;
> +
> + if (vector == POSTED_INTR_WAKEUP_VECTOR &&
> + (handler == dummy_handler ||
> + kvm_posted_intr_wakeup_handler == dummy_handler))
> kvm_posted_intr_wakeup_handler = handler;
> - else {
> - kvm_posted_intr_wakeup_handler = dummy_handler;
> + else
> + WARN_ON_ONCE(1);
> +
> + if (handler == dummy_handler)
Eww. Aside from the fact that the dummy_handler implementation is pointless
overhead, I don't think KVM should own the IRQ vector. Given that perf owns the
LVTPC, i.e. responsible for switching between NMI and the medited PMI IRQ, I
think perf should also own the vector. KVM can then use the existing perf guest
callbacks to wire up its PMI handler.
And with that, this patch can be dropped.
