port-xen/59212: XEN3_DOM0 panics as NR_PIRQS is too small

[netbsd%precedence.co.uk@localhost]

>Number:         59212
>Category:       port-xen
>Synopsis:       XEN3_DOM0 panics as NR_PIRQS is too small
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-xen-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Mar 25 13:00:00 +0000 2025
>Originator:     Stephen Borrill
>Release:        10.1_STABLE
>Organization:
>Environment:
NetBSD xen1 10.1_STABLE NetBSD 10.1_STABLE (XEN3_DOM0) #2: Mon Mar 24 14:12:59 GMT 2025  root@builder10:/usr/work/obj/10/amd64/sys/arch/amd64/compile/XEN3_DOM0 amd64

>Description:
I have an IBM x3550M4 server. 10.1_STABLE GENERIC boots fine. Booting XEN3_DOM0 panics during device attachment:

[   1.0000030] mfii0 at pci4 dev 0 function 0: "ServeRAID M5110", firmware 23.34.0-0023, 512MB cache
[   1.0000030] panic: pirq 4991 out of bound, increase NR_PIRQS
[   1.0000030] cpu0: Begin traceback...
[   1.0000030] vpanic() at netbsd:vpanic+0x177
[   1.0000030] panic() at netbsd:panic+0x3c
[   1.0000030] bind_pirq_to_evtch() at netbsd:bind_pirq_to_evtch+0x97

From sys/arch/xen/xen/evtchn.c:

#define NR_PIRQS        NR_EVENT_CHANNELS

This equates to 4096 and, indeed, 4991 is greater than 4096.

>How-To-Repeat:
Boot XEN3_DOM0 kernel on an IBM x3550M4 (likely other server-spec hardware too).
>Fix:
A workaround, not a fix, is to increase NR_PIRQS as follows:

--- sys/arch/xen/xen/evtchn.c   7 Sep 2022 00:40:19 -0000       1.100
+++ sys/arch/xen/xen/evtchn.c   24 Mar 2025 14:18:26 -0000
@@ -89,7 +89,7 @@
 #define NBSD_XEN_MAX_VCPUS HVM_MAX_VCPUS
 #endif

-#define        NR_PIRQS        NR_EVENT_CHANNELS
+#define        NR_PIRQS        (NR_EVENT_CHANNELS*2)

 /*
  * This lock protects updates to the following mapping and reference-count