Re: [PATCH] PCI: brcmstb: Reserve only the MSI vectors that are handed out

> Because bitmap_set only reserves exactly nr_irqs bits, the remaining bits in
> the device's hardware window remain marked as free in the allocator. If
> another device is subsequently assigned one of these trailing vectors, can
> the first device's interrupts be incorrectly routed to the second device?

No. The PCI/MSI core masks every vector the endpoint is capable of and
then unmasks only the ones that were handed out, so the endpoint cannot
signal the trailing vectors of its window.

msi_capability_init() masks the full capable range:

  /* drivers/pci/msi/msi.c */
  /* All MSIs are unmasked by default; mask them all */
  entry = msi_first_desc(&dev->dev, MSI_DESC_ALL);
  pci_msi_mask(entry, msi_multi_mask(entry));

And each allocated vector is unmasked individually:

  /* drivers/pci/msi/irqdomain.c */
  pci_msi_unmask(desc, BIT(data->irq - desc->irq));

This is observable in config space on the endpoint I tested. With 5
vectors handed out at hwirq 0x8 and Multiple Message Enable programmed to
8, the Mask Bits register reads 0x0000ffe0: bits 0-4 (the vectors in use)
open, bits 5-15 masked. Messages 5-7, which would land on hwirq 0xd-0xf,
are blocked at the device.

Reserving the full power-of-two block does not provide isolation either;
it just never releases it. The irqdomain core calls ops->free() once per
vector with nr_irqs == 1, so bitmap_release_region(order_base_2(1))
clears a single bit per call, and roundup_pow_of_two(nr_irqs) - nr_irqs
bits stay set for the lifetime of the controller. That is the leak this
patch fixes.

irqchip/gic-v2m.c and irqchip/irq-alpine-msi.c already reserve exactly
nr_irqs this way. For instance, gic-v2m moved to
bitmap_find_next_zero_area_off() + bitmap_set(nr_irqs) in commit
2ef3886ce626 ("irqchip/gic-v2m: Handle Multiple MSI base IRQ Alignment").

Thanks,
Sangwoo