1 The MSI Driver Guide HOWTO 2 Tom L Nguyen tom.l.nguyen@intel.com 3 10/03/2003 4 Revised Feb 12, 2004 by Martine Silbermann 5 email: Martine.Silbermann@hp.com 6 Revised Jun 25, 2004 by Tom L Nguyen 7 Revised Jul 9, 2008 by Matthew Wilcox <willy@linux.intel.com> 8 Copyright 2003, 2008 Intel Corporation 9 101. About this guide 11 12This guide describes the basics of Message Signaled Interrupts (MSIs), 13the advantages of using MSI over traditional interrupt mechanisms, how 14to change your driver to use MSI or MSI-X and some basic diagnostics to 15try if a device doesn't support MSIs. 16 17 182. What are MSIs? 19 20A Message Signaled Interrupt is a write from the device to a special 21address which causes an interrupt to be received by the CPU. 22 23The MSI capability was first specified in PCI 2.2 and was later enhanced 24in PCI 3.0 to allow each interrupt to be masked individually. The MSI-X 25capability was also introduced with PCI 3.0. It supports more interrupts 26per device than MSI and allows interrupts to be independently configured. 27 28Devices may support both MSI and MSI-X, but only one can be enabled at 29a time. 30 31 323. Why use MSIs? 33 34There are three reasons why using MSIs can give an advantage over 35traditional pin-based interrupts. 36 37Pin-based PCI interrupts are often shared amongst several devices. 38To support this, the kernel must call each interrupt handler associated 39with an interrupt, which leads to reduced performance for the system as 40a whole. MSIs are never shared, so this problem cannot arise. 41 42When a device writes data to memory, then raises a pin-based interrupt, 43it is possible that the interrupt may arrive before all the data has 44arrived in memory (this becomes more likely with devices behind PCI-PCI 45bridges). In order to ensure that all the data has arrived in memory, 46the interrupt handler must read a register on the device which raised 47the interrupt. PCI transaction ordering rules require that all the data 48arrives in memory before the value can be returned from the register. 49Using MSIs avoids this problem as the interrupt-generating write cannot 50pass the data writes, so by the time the interrupt is raised, the driver 51knows that all the data has arrived in memory. 52 53PCI devices can only support a single pin-based interrupt per function. 54Often drivers have to query the device to find out what event has 55occurred, slowing down interrupt handling for the common case. With 56MSIs, a device can support more interrupts, allowing each interrupt 57to be specialised to a different purpose. One possible design gives 58infrequent conditions (such as errors) their own interrupt which allows 59the driver to handle the normal interrupt handling path more efficiently. 60Other possible designs include giving one interrupt to each packet queue 61in a network card or each port in a storage controller. 62 63 644. How to use MSIs 65 66PCI devices are initialised to use pin-based interrupts. The device 67driver has to set up the device to use MSI or MSI-X. Not all machines 68support MSIs correctly, and for those machines, the APIs described below 69will simply fail and the device will continue to use pin-based interrupts. 70 714.1 Include kernel support for MSIs 72 73To support MSI or MSI-X, the kernel must be built with the CONFIG_PCI_MSI 74option enabled. This option is only available on some architectures, 75and it may depend on some other options also being set. For example, 76on x86, you must also enable X86_UP_APIC or SMP in order to see the 77CONFIG_PCI_MSI option. 78 794.2 Using MSI 80 81Most of the hard work is done for the driver in the PCI layer. It simply 82has to request that the PCI layer set up the MSI capability for this 83device. 84 854.2.1 pci_enable_msi 86 87int pci_enable_msi(struct pci_dev *dev) 88 89A successful call will allocate ONE interrupt to the device, regardless 90of how many MSIs the device supports. The device will be switched from 91pin-based interrupt mode to MSI mode. The dev->irq number is changed 92to a new number which represents the message signaled interrupt. 93This function should be called before the driver calls request_irq() 94since enabling MSIs disables the pin-based IRQ and the driver will not 95receive interrupts on the old interrupt. 96 974.2.2 pci_enable_msi_block 98 99int pci_enable_msi_block(struct pci_dev *dev, int count) 100 101This variation on the above call allows a device driver to request multiple 102MSIs. The MSI specification only allows interrupts to be allocated in 103powers of two, up to a maximum of 2^5 (32). 104 105If this function returns 0, it has succeeded in allocating at least as many 106interrupts as the driver requested (it may have allocated more in order 107to satisfy the power-of-two requirement). In this case, the function 108enables MSI on this device and updates dev->irq to be the lowest of 109the new interrupts assigned to it. The other interrupts assigned to 110the device are in the range dev->irq to dev->irq + count - 1. 111 112If this function returns a negative number, it indicates an error and 113the driver should not attempt to request any more MSI interrupts for 114this device. If this function returns a positive number, it will be 115less than 'count' and indicate the number of interrupts that could have 116been allocated. In neither case will the irq value have been 117updated, nor will the device have been switched into MSI mode. 118 119The device driver must decide what action to take if 120pci_enable_msi_block() returns a value less than the number asked for. 121Some devices can make use of fewer interrupts than the maximum they 122request; in this case the driver should call pci_enable_msi_block() 123again. Note that it is not guaranteed to succeed, even when the 124'count' has been reduced to the value returned from a previous call to 125pci_enable_msi_block(). This is because there are multiple constraints 126on the number of vectors that can be allocated; pci_enable_msi_block() 127will return as soon as it finds any constraint that doesn't allow the 128call to succeed. 129 1304.2.3 pci_disable_msi 131 132void pci_disable_msi(struct pci_dev *dev) 133 134This function should be used to undo the effect of pci_enable_msi() or 135pci_enable_msi_block(). Calling it restores dev->irq to the pin-based 136interrupt number and frees the previously allocated message signaled 137interrupt(s). The interrupt may subsequently be assigned to another 138device, so drivers should not cache the value of dev->irq. 139 140A device driver must always call free_irq() on the interrupt(s) 141for which it has called request_irq() before calling this function. 142Failure to do so will result in a BUG_ON(), the device will be left with 143MSI enabled and will leak its vector. 144 1454.3 Using MSI-X 146 147The MSI-X capability is much more flexible than the MSI capability. 148It supports up to 2048 interrupts, each of which can be controlled 149independently. To support this flexibility, drivers must use an array of 150`struct msix_entry': 151 152struct msix_entry { 153 u16 vector; /* kernel uses to write alloc vector */ 154 u16 entry; /* driver uses to specify entry */ 155}; 156 157This allows for the device to use these interrupts in a sparse fashion; 158for example it could use interrupts 3 and 1027 and allocate only a 159two-element array. The driver is expected to fill in the 'entry' value 160in each element of the array to indicate which entries it wants the kernel 161to assign interrupts for. It is invalid to fill in two entries with the 162same number. 163 1644.3.1 pci_enable_msix 165 166int pci_enable_msix(struct pci_dev *dev, struct msix_entry *entries, int nvec) 167 168Calling this function asks the PCI subsystem to allocate 'nvec' MSIs. 169The 'entries' argument is a pointer to an array of msix_entry structs 170which should be at least 'nvec' entries in size. On success, the 171function will return 0 and the device will have been switched into 172MSI-X interrupt mode. The 'vector' elements in each entry will have 173been filled in with the interrupt number. The driver should then call 174request_irq() for each 'vector' that it decides to use. 175 176If this function returns a negative number, it indicates an error and 177the driver should not attempt to allocate any more MSI-X interrupts for 178this device. If it returns a positive number, it indicates the maximum 179number of interrupt vectors that could have been allocated. See example 180below. 181 182This function, in contrast with pci_enable_msi(), does not adjust 183dev->irq. The device will not generate interrupts for this interrupt 184number once MSI-X is enabled. The device driver is responsible for 185keeping track of the interrupts assigned to the MSI-X vectors so it can 186free them again later. 187 188Device drivers should normally call this function once per device 189during the initialization phase. 190 191It is ideal if drivers can cope with a variable number of MSI-X interrupts, 192there are many reasons why the platform may not be able to provide the 193exact number a driver asks for. 194 195A request loop to achieve that might look like: 196 197static int foo_driver_enable_msix(struct foo_adapter *adapter, int nvec) 198{ 199 while (nvec >= FOO_DRIVER_MINIMUM_NVEC) { 200 rc = pci_enable_msix(adapter->pdev, 201 adapter->msix_entries, nvec); 202 if (rc > 0) 203 nvec = rc; 204 else 205 return rc; 206 } 207 208 return -ENOSPC; 209} 210 2114.3.2 pci_disable_msix 212 213void pci_disable_msix(struct pci_dev *dev) 214 215This API should be used to undo the effect of pci_enable_msix(). It frees 216the previously allocated message signaled interrupts. The interrupts may 217subsequently be assigned to another device, so drivers should not cache 218the value of the 'vector' elements over a call to pci_disable_msix(). 219 220A device driver must always call free_irq() on the interrupt(s) 221for which it has called request_irq() before calling this function. 222Failure to do so will result in a BUG_ON(), the device will be left with 223MSI enabled and will leak its vector. 224 2254.3.3 The MSI-X Table 226 227The MSI-X capability specifies a BAR and offset within that BAR for the 228MSI-X Table. This address is mapped by the PCI subsystem, and should not 229be accessed directly by the device driver. If the driver wishes to 230mask or unmask an interrupt, it should call disable_irq() / enable_irq(). 231 2324.4 Handling devices implementing both MSI and MSI-X capabilities 233 234If a device implements both MSI and MSI-X capabilities, it can 235run in either MSI mode or MSI-X mode but not both simultaneously. 236This is a requirement of the PCI spec, and it is enforced by the 237PCI layer. Calling pci_enable_msi() when MSI-X is already enabled or 238pci_enable_msix() when MSI is already enabled will result in an error. 239If a device driver wishes to switch between MSI and MSI-X at runtime, 240it must first quiesce the device, then switch it back to pin-interrupt 241mode, before calling pci_enable_msi() or pci_enable_msix() and resuming 242operation. This is not expected to be a common operation but may be 243useful for debugging or testing during development. 244 2454.5 Considerations when using MSIs 246 2474.5.1 Choosing between MSI-X and MSI 248 249If your device supports both MSI-X and MSI capabilities, you should use 250the MSI-X facilities in preference to the MSI facilities. As mentioned 251above, MSI-X supports any number of interrupts between 1 and 2048. 252In constrast, MSI is restricted to a maximum of 32 interrupts (and 253must be a power of two). In addition, the MSI interrupt vectors must 254be allocated consecutively, so the system may not be able to allocate 255as many vectors for MSI as it could for MSI-X. On some platforms, MSI 256interrupts must all be targetted at the same set of CPUs whereas MSI-X 257interrupts can all be targetted at different CPUs. 258 2594.5.2 Spinlocks 260 261Most device drivers have a per-device spinlock which is taken in the 262interrupt handler. With pin-based interrupts or a single MSI, it is not 263necessary to disable interrupts (Linux guarantees the same interrupt will 264not be re-entered). If a device uses multiple interrupts, the driver 265must disable interrupts while the lock is held. If the device sends 266a different interrupt, the driver will deadlock trying to recursively 267acquire the spinlock. 268 269There are two solutions. The first is to take the lock with 270spin_lock_irqsave() or spin_lock_irq() (see 271Documentation/DocBook/kernel-locking). The second is to specify 272IRQF_DISABLED to request_irq() so that the kernel runs the entire 273interrupt routine with interrupts disabled. 274 275If your MSI interrupt routine does not hold the lock for the whole time 276it is running, the first solution may be best. The second solution is 277normally preferred as it avoids making two transitions from interrupt 278disabled to enabled and back again. 279 2804.6 How to tell whether MSI/MSI-X is enabled on a device 281 282Using 'lspci -v' (as root) may show some devices with "MSI", "Message 283Signalled Interrupts" or "MSI-X" capabilities. Each of these capabilities 284has an 'Enable' flag which will be followed with either "+" (enabled) 285or "-" (disabled). 286 287 2885. MSI quirks 289 290Several PCI chipsets or devices are known not to support MSIs. 291The PCI stack provides three ways to disable MSIs: 292 2931. globally 2942. on all devices behind a specific bridge 2953. on a single device 296 2975.1. Disabling MSIs globally 298 299Some host chipsets simply don't support MSIs properly. If we're 300lucky, the manufacturer knows this and has indicated it in the ACPI 301FADT table. In this case, Linux will automatically disable MSIs. 302Some boards don't include this information in the table and so we have 303to detect them ourselves. The complete list of these is found near the 304quirk_disable_all_msi() function in drivers/pci/quirks.c. 305 306If you have a board which has problems with MSIs, you can pass pci=nomsi 307on the kernel command line to disable MSIs on all devices. It would be 308in your best interests to report the problem to linux-pci@vger.kernel.org 309including a full 'lspci -v' so we can add the quirks to the kernel. 310 3115.2. Disabling MSIs below a bridge 312 313Some PCI bridges are not able to route MSIs between busses properly. 314In this case, MSIs must be disabled on all devices behind the bridge. 315 316Some bridges allow you to enable MSIs by changing some bits in their 317PCI configuration space (especially the Hypertransport chipsets such 318as the nVidia nForce and Serverworks HT2000). As with host chipsets, 319Linux mostly knows about them and automatically enables MSIs if it can. 320If you have a bridge which Linux doesn't yet know about, you can enable 321MSIs in configuration space using whatever method you know works, then 322enable MSIs on that bridge by doing: 323 324 echo 1 > /sys/bus/pci/devices/$bridge/msi_bus 325 326where $bridge is the PCI address of the bridge you've enabled (eg 3270000:00:0e.0). 328 329To disable MSIs, echo 0 instead of 1. Changing this value should be 330done with caution as it can break interrupt handling for all devices 331below this bridge. 332 333Again, please notify linux-pci@vger.kernel.org of any bridges that need 334special handling. 335 3365.3. Disabling MSIs on a single device 337 338Some devices are known to have faulty MSI implementations. Usually this 339is handled in the individual device driver but occasionally it's necessary 340to handle this with a quirk. Some drivers have an option to disable use 341of MSI. While this is a convenient workaround for the driver author, 342it is not good practise, and should not be emulated. 343 3445.4. Finding why MSIs are disabled on a device 345 346From the above three sections, you can see that there are many reasons 347why MSIs may not be enabled for a given device. Your first step should 348be to examine your dmesg carefully to determine whether MSIs are enabled 349for your machine. You should also check your .config to be sure you 350have enabled CONFIG_PCI_MSI. 351 352Then, 'lspci -t' gives the list of bridges above a device. Reading 353/sys/bus/pci/devices/*/msi_bus will tell you whether MSI are enabled (1) 354or disabled (0). If 0 is found in any of the msi_bus files belonging 355to bridges between the PCI root and the device, MSIs are disabled. 356 357It is also worth checking the device driver to see whether it supports MSIs. 358For example, it may contain calls to pci_enable_msi(), pci_enable_msix() or 359pci_enable_msi_block(). 360