On 5/15/2025 7:21 AM, Sean Christopherson wrote:
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.
Hmm, yes, make sense.
And with that, this patch can be dropped.