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))
- 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.