Hi Thomas, Dave,
Seeking your inputs on the below direction.
On 7/10/2025 3:40 PM, Sean Christopherson wrote:
>>> One thought would be to pass a small struct (by value), and then provide
>>> macros
>>> to generate the structure for a specific vector. That provides some amount
>>> of
>>> type safety and should make it a bit harder to pass in garbage, without
>>> making
>>> the callers any less readable.
>>>
>>> struct apic_ipi {
>>> u8 vector;
>>> u8 type;
>>> };
>>>
>>> #define APIC_IPI(v, t) ({ struct apic_ipi i = { .vector = v, .type = t };
>>> i; })
>>> #define APIC_IPI_IRQ(vector) APIC_IPI(vector, APIC_DELIVERY_MODE_FIXED)
>>> #define APIC_IPI_NMI(vector) APIC_IPI(vector, APIC_DELIVERY_MODE_NMI)
>>>
>>> #define IPI_IRQ_WORK APIC_IPI_IRQ(IRQ_WORK_VECTOR)
>>> #define IPI_POSTED_INTR_WAKEUP APIC_IPI_IRQ(POSTED_INTR_WAKEUP_VECTOR)
>>>
>>> #define IPI_NMI_BACKTRACE APIC_IPI_NMI(NMI_BACKTRACE_VECTOR)
>>>
>>> static __always_inline void __apic_send_IPI_self(struct apic_ipi ipi)
>>
>> I am fine with this approach. Though, the changes would be massive since
>> we have quite a few interfaces and a lot of "struct apic".
>
> It'd definitely be big, but it doesn't seem like it'd be overwhelmingly
> painful.
> Though it's certainly enough churn that I wouldn't do anything until there's a
> consensus one way or the other :-)
>
In order to accommodate NMI source vectors, updating the send_IPI_*()
APIs seems like the right thing to do for the long run. But it would
introduce some churn. Is this the optimal path forward? Any other
options we should consider?
