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))
>> 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.
Hmm, yes, make sense.
>
> And with that, this patch can be dropped.
>
