The prior implementation of xen_intr_resume() was (ab)using the x86
interrupt list as a table of in-use interrupts. Rework this to instead
use the xen_intr_port_to_isrc array for this purpose. This removes one
more x86-ism from xen_intr.c, a major benefit.
This is the main goal of D30598/D30599. The variables xen_intr_auto_vector_count and first_evtchn_irq are x86-specific. The call intr_lookup_source() is also x86-specific which is being utilized to get access to interrupt_sources and use that as a table of allocated event channel interrupts. These two make it so xen_intr_port_to_isrc is used for this purpose instead.
xen_intr_auto_vector and first_evtchn_irq are attempting to head back into sys/x86/xen land, while xen_intr_port_to_isrc is definitely going to remain in sys/xen/xen_intr.c. Since the functionality of xen_intr_resume() requires access to xen_intr_port_to_isrc, removing references to xen_intr_auto_vector and first_evtchn_irq pushes the effort to get those out of sys/xen/xen_intr.c forward.
Actually, one question for the FreeBSD/Xen maintainer: Is the order of the xen_intr_port_to_isrc[cur->xi_port] = cur; and evtchn_unmask_port(cur->xi_port); lines important?
I suspect it is since the moment the event channel port is unmasked, events can occur. As such I moved the second call out of xen_intr_rebind_isrc(), but if it is acceptable to have those in the opposite order then having that remain in the function would be nice. I was guessing this would be a race condition and therefore opted for the safe choice.
Due to this code, one could argue for adding a evtchn_port_t max_port;. The purpose being to keep track of the maximum used port. Before this commit xen_intr_auto_vector_count was being abused for this. Problem of course is at D30936 that variable becomes unavailable and this file needs a separate tracking variable.