intr/x86: allow passing stray message into intr_execute_handlers()

[ehem_freebsd_m5p.com]

Summary

One caller wants to report something distinct in case of stray interrupt.
Additionally this removes the need to pass the vector.

[ehem_freebsd_m5p.com]

I hope this would be acceptable to the INTRNG/ARM/RISC-V developers as a potential common behavior with intr_isrc_dispatch(). Mainly the INTRNG code is written to have the caller report stray interrupts, whereas intr_execute_handlers() is written to report stray interrupts internally. Pass NULL for the two arguments and you get behavior similar to intr_isrc_dispatch(), pass the standard strings and it acts similar to intr_execute_handlers().

sys/dev/xen/bus/xen_intr.c

569

This diff may be slightly off due to the number of patches in my tree under review. This is the actual target, the Xen event channel code ends up keeping the vector number around for no purpose other than this single call. If the text produced states it is the event channel number, not the irq structure number we become free to purge the value.

sys/x86/isa/atpic.c

552

I think vector is the same as what atpic_vector(isrc) is, but I'm less than 100% certain here. This file has some oddities.

[ehem_freebsd_m5p.com]

Erk, need braces in this case. Include them on the else for consistency.

[ehem_freebsd_m5p.com]

Lack of response seems to suggest either this will be controversial or is likely to be rejected...

The alternative which comes to mind would be to place the logging block inside a if (vector != ~(u_long)0) { }. Mainly the all ones vector tells intr_execute_handlers() not to produce a message on stray. This would also fulfill the purpose of modifying the interface in a way which INTRNG could be compatible with.

[royger]

sys/dev/xen/bus/xen_intr.c

569

Printing port here is not helpful from a user PoV, as the port cannot be matched with the output from vmstat -i for example.

I guess this is already picked up from previous patches that already wrongly pass first_evtchn_irq + port instead of the vector value provided in intr_register_source().

[ehem_freebsd_m5p.com]

Since this seems unlikely to be accepted right now, I guess I'll have to abandon this path for now.

sys/dev/xen/bus/xen_intr.c

569

I guess this is already picked up from previous patches that already wrongly pass first_evtchn_irq + port instead of the vector value provided in intr_register_source().

This is what I meant "be slightly off due to the number of patches in my tree".