> Date: Wed, 4 May 2016 07:14:15 -0700 > From: Mike Larkin <mlar...@azathoth.net> > > On Wed, May 04, 2016 at 04:01:54PM +0200, Mike Belopuhov wrote: > > On Tue, May 03, 2016 at 21:40 +0200, Mark Kettenis wrote: > > > Today mpi@ reminded me that I had written support for MSI-X some time > > > ago. Since he is interested in using multiple vectors, I extended the > > > code I had a bit to support that feature as well. This introduces a > > > new function: > > > > > > int pci_intr_map_msix(struct pci_attach_args *, int, pci_intr_handle_t *); > > > > > > You use it like pci_intr_map_msi(9) and pci_intr_map(9), buthave to > > > pass it a vector number as the 2nd argument. Typically you'll pass 0, > > > wich will map the 1st vector, which is always there on hardware with > > > MSI-X support. Some hardware supports more than 1 vector. Typical > > > examples are network cards that support multiple rings. Please be > > > aware that on architectures like i386 and amd64, the number of > > > interrupt vectors at each level is limited. If you consume too many > > > of them, devices may fail to attach. > > > > > > As for the implementation. This only adds code for amd64. I'll > > > probably add support for sparc64 as well. I'm hesitant about i386 > > > because it has even less available interrupt vectors than amd64. > > > > > > Notice that the amd64 implementation uses _bus_space_map() and > > > _bus_space_unmap(). That is deliberate. The MSI-X registers miht > > > share a BAR with other registers that our drivers already map. The > > > underscored versions of the mapping routines make sure that we don't > > > fail to map things in that case. > > > > > > ok? > > > > > > > This is great, thanks for doing this! I'm a bit surprised that > > we don't need to the same suspend/resume dance in ppb(4) as with > > MSI. > > > > That is an excellent point I overlooked. Kettenis, do we?
Almost certainly. I committed the diff, but left the bits out that start using it in em(4) and xhci(4).
