The number of MSI IRQs still defaults to 512, but it can now be changed at
boot time via the machdep.num_msi_irqs tunable.
Details
Details
- booted a bhyve VM similar to the setup described in D17976. With machdep.num_msi_irqs=11 it had the same correct behavior described in the test plan for D17976.
Note, xen_msi might need it's own validation as it doesn't seem prepared
to cope with num_msi_irqs == 0, for example. I have not tested XEN.
Diff Detail
Diff Detail
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 20811 Build 20205: arc lint + arc unit
Event Timeline
| sys/x86/x86/msi.c | ||
|---|---|---|
| 343–345 | I think at a minimum I should add an overflow check here actually. | |
| sys/x86/xen/xen_intr.c | ||
|---|---|---|
| 693 | So sadly clang omits this overflow check though it keeps the one in msi.c. I was testing by setting machdep.num_msi_irqs to 0xfffffff00 which panicked in msi.c and then tried 0xfffffeff which should have panicked here but didn't and just overflowed num_io_irqs to 4095. | |
| sys/x86/xen/xen_intr.c | ||
|---|---|---|
| 693 | Do you need to cast NR_EVENT_CHANNELS to u_int? | |
| sys/x86/xen/xen_intr.c | ||
|---|---|---|
| 693 | Thanks to Mark for noticing that NR_EVENT_CHANNELS ends up being a size_t which is why the original expression was always false. This one works. Note that trying to boot with a large number of interrupts that didn't overflow wasn't very productive as the interrupt_sources[] array can be nearly 4GB and that's an awfully large size to pass to malloc(). | |
| sys/x86/xen/xen_msi.c | ||
|---|---|---|
| 61–63 | Hmm, it'd be consistent to convert this to if (num_msi_irqs > UINT_MAX - first_msi_irqs). | |