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
- 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
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
sys/x86/x86/msi.c | ||
---|---|---|
343 ↗ | (On Diff #50370) | I think at a minimum I should add an overflow check here actually. |
sys/x86/xen/xen_intr.c | ||
---|---|---|
693 ↗ | (On Diff #50424) | 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 ↗ | (On Diff #50424) | Do you need to cast NR_EVENT_CHANNELS to u_int? |
sys/x86/xen/xen_intr.c | ||
---|---|---|
693 ↗ | (On Diff #50424) | 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 | ||
---|---|---|
60 ↗ | (On Diff #50424) | Hmm, it'd be consistent to convert this to if (num_msi_irqs > UINT_MAX - first_msi_irqs). |