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.

The key point behind D30598/D30599 is xen_intr_port_to_isrc[] is part of the xen_intr.c file, whereas intr_lookup_source is using the x86-only interrupt_sources[] array for the purpose. As such this removes another x86-ism from the file. I could see these two being squashed in the end.

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.