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 48arrive in memory before the value may 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 allocates ONE interrupt to the device, regardless 90of how many MSIs the device supports. The device is 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; 93consequently, this function should be called before the driver calls 94request_irq(), because an MSI is delivered via a vector that is 95different from the vector of a pin-based interrupt. 96 974.2.2 pci_enable_msi_range 98 99int pci_enable_msi_range(struct pci_dev *dev, int minvec, int maxvec) 100 101This function allows a device driver to request any number of MSI 102interrupts within specified range from 'minvec' to 'maxvec'. 103 104If this function returns a positive number it indicates the number of 105MSI interrupts that have been successfully allocated. In this case 106the device is switched from pin-based interrupt mode to MSI mode and 107updates dev->irq to be the lowest of the new interrupts assigned to it. 108The other interrupts assigned to the device are in the range dev->irq 109to dev->irq + returned value - 1. Device driver can use the returned 110number of successfully allocated MSI interrupts to further allocate 111and initialize device resources. 112 113If this function returns a negative number, it indicates an error and 114the driver should not attempt to request any more MSI interrupts for 115this device. 116 117This function should be called before the driver calls request_irq(), 118because MSI interrupts are delivered via vectors that are different 119from the vector of a pin-based interrupt. 120 121It is ideal if drivers can cope with a variable number of MSI interrupts; 122there are many reasons why the platform may not be able to provide the 123exact number that a driver asks for. 124 125There could be devices that can not operate with just any number of MSI 126interrupts within a range. See chapter 4.3.1.3 to get the idea how to 127handle such devices for MSI-X - the same logic applies to MSI. 128 1294.2.1.1 Maximum possible number of MSI interrupts 130 131The typical usage of MSI interrupts is to allocate as many vectors as 132possible, likely up to the limit returned by pci_msi_vec_count() function: 133 134static int foo_driver_enable_msi(struct pci_dev *pdev, int nvec) 135{ 136 return pci_enable_msi_range(pdev, 1, nvec); 137} 138 139Note the value of 'minvec' parameter is 1. As 'minvec' is inclusive, 140the value of 0 would be meaningless and could result in error. 141 142Some devices have a minimal limit on number of MSI interrupts. 143In this case the function could look like this: 144 145static int foo_driver_enable_msi(struct pci_dev *pdev, int nvec) 146{ 147 return pci_enable_msi_range(pdev, FOO_DRIVER_MINIMUM_NVEC, nvec); 148} 149 1504.2.1.2 Exact number of MSI interrupts 151 152If a driver is unable or unwilling to deal with a variable number of MSI 153interrupts it could request a particular number of interrupts by passing 154that number to pci_enable_msi_range() function as both 'minvec' and 'maxvec' 155parameters: 156 157static int foo_driver_enable_msi(struct pci_dev *pdev, int nvec) 158{ 159 return pci_enable_msi_range(pdev, nvec, nvec); 160} 161 162Note, unlike pci_enable_msi_exact() function, which could be also used to 163enable a particular number of MSI-X interrupts, pci_enable_msi_range() 164returns either a negative errno or 'nvec' (not negative errno or 0 - as 165pci_enable_msi_exact() does). 166 1674.2.1.3 Single MSI mode 168 169The most notorious example of the request type described above is 170enabling the single MSI mode for a device. It could be done by passing 171two 1s as 'minvec' and 'maxvec': 172 173static int foo_driver_enable_single_msi(struct pci_dev *pdev) 174{ 175 return pci_enable_msi_range(pdev, 1, 1); 176} 177 178Note, unlike pci_enable_msi() function, which could be also used to 179enable the single MSI mode, pci_enable_msi_range() returns either a 180negative errno or 1 (not negative errno or 0 - as pci_enable_msi() 181does). 182 1834.2.3 pci_enable_msi_exact 184 185int pci_enable_msi_exact(struct pci_dev *dev, int nvec) 186 187This variation on pci_enable_msi_range() call allows a device driver to 188request exactly 'nvec' MSIs. 189 190If this function returns a negative number, it indicates an error and 191the driver should not attempt to request any more MSI interrupts for 192this device. 193 194By contrast with pci_enable_msi_range() function, pci_enable_msi_exact() 195returns zero in case of success, which indicates MSI interrupts have been 196successfully allocated. 197 1984.2.4 pci_disable_msi 199 200void pci_disable_msi(struct pci_dev *dev) 201 202This function should be used to undo the effect of pci_enable_msi_range(). 203Calling it restores dev->irq to the pin-based interrupt number and frees 204the previously allocated MSIs. The interrupts may subsequently be assigned 205to another device, so drivers should not cache the value of dev->irq. 206 207Before calling this function, a device driver must always call free_irq() 208on any interrupt for which it previously called request_irq(). 209Failure to do so results in a BUG_ON(), leaving the device with 210MSI enabled and thus leaking its vector. 211 2124.2.4 pci_msi_vec_count 213 214int pci_msi_vec_count(struct pci_dev *dev) 215 216This function could be used to retrieve the number of MSI vectors the 217device requested (via the Multiple Message Capable register). The MSI 218specification only allows the returned value to be a power of two, 219up to a maximum of 2^5 (32). 220 221If this function returns a negative number, it indicates the device is 222not capable of sending MSIs. 223 224If this function returns a positive number, it indicates the maximum 225number of MSI interrupt vectors that could be allocated. 226 2274.3 Using MSI-X 228 229The MSI-X capability is much more flexible than the MSI capability. 230It supports up to 2048 interrupts, each of which can be controlled 231independently. To support this flexibility, drivers must use an array of 232`struct msix_entry': 233 234struct msix_entry { 235 u16 vector; /* kernel uses to write alloc vector */ 236 u16 entry; /* driver uses to specify entry */ 237}; 238 239This allows for the device to use these interrupts in a sparse fashion; 240for example, it could use interrupts 3 and 1027 and yet allocate only a 241two-element array. The driver is expected to fill in the 'entry' value 242in each element of the array to indicate for which entries the kernel 243should assign interrupts; it is invalid to fill in two entries with the 244same number. 245 2464.3.1 pci_enable_msix_range 247 248int pci_enable_msix_range(struct pci_dev *dev, struct msix_entry *entries, 249 int minvec, int maxvec) 250 251Calling this function asks the PCI subsystem to allocate any number of 252MSI-X interrupts within specified range from 'minvec' to 'maxvec'. 253The 'entries' argument is a pointer to an array of msix_entry structs 254which should be at least 'maxvec' entries in size. 255 256On success, the device is switched into MSI-X mode and the function 257returns the number of MSI-X interrupts that have been successfully 258allocated. In this case the 'vector' member in entries numbered from 2590 to the returned value - 1 is populated with the interrupt number; 260the driver should then call request_irq() for each 'vector' that it 261decides to use. The device driver is responsible for keeping track of the 262interrupts assigned to the MSI-X vectors so it can free them again later. 263Device driver can use the returned number of successfully allocated MSI-X 264interrupts to further allocate and initialize device resources. 265 266If this function returns a negative number, it indicates an error and 267the driver should not attempt to allocate any more MSI-X interrupts for 268this device. 269 270This function, in contrast with pci_enable_msi_range(), does not adjust 271dev->irq. The device will not generate interrupts for this interrupt 272number once MSI-X is enabled. 273 274Device drivers should normally call this function once per device 275during the initialization phase. 276 277It is ideal if drivers can cope with a variable number of MSI-X interrupts; 278there are many reasons why the platform may not be able to provide the 279exact number that a driver asks for. 280 281There could be devices that can not operate with just any number of MSI-X 282interrupts within a range. E.g., an network adapter might need let's say 283four vectors per each queue it provides. Therefore, a number of MSI-X 284interrupts allocated should be a multiple of four. In this case interface 285pci_enable_msix_range() can not be used alone to request MSI-X interrupts 286(since it can allocate any number within the range, without any notion of 287the multiple of four) and the device driver should master a custom logic 288to request the required number of MSI-X interrupts. 289 2904.3.1.1 Maximum possible number of MSI-X interrupts 291 292The typical usage of MSI-X interrupts is to allocate as many vectors as 293possible, likely up to the limit returned by pci_msix_vec_count() function: 294 295static int foo_driver_enable_msix(struct foo_adapter *adapter, int nvec) 296{ 297 return pci_enable_msix_range(adapter->pdev, adapter->msix_entries, 298 1, nvec); 299} 300 301Note the value of 'minvec' parameter is 1. As 'minvec' is inclusive, 302the value of 0 would be meaningless and could result in error. 303 304Some devices have a minimal limit on number of MSI-X interrupts. 305In this case the function could look like this: 306 307static int foo_driver_enable_msix(struct foo_adapter *adapter, int nvec) 308{ 309 return pci_enable_msix_range(adapter->pdev, adapter->msix_entries, 310 FOO_DRIVER_MINIMUM_NVEC, nvec); 311} 312 3134.3.1.2 Exact number of MSI-X interrupts 314 315If a driver is unable or unwilling to deal with a variable number of MSI-X 316interrupts it could request a particular number of interrupts by passing 317that number to pci_enable_msix_range() function as both 'minvec' and 'maxvec' 318parameters: 319 320static int foo_driver_enable_msix(struct foo_adapter *adapter, int nvec) 321{ 322 return pci_enable_msix_range(adapter->pdev, adapter->msix_entries, 323 nvec, nvec); 324} 325 326Note, unlike pci_enable_msix_exact() function, which could be also used to 327enable a particular number of MSI-X interrupts, pci_enable_msix_range() 328returns either a negative errno or 'nvec' (not negative errno or 0 - as 329pci_enable_msix_exact() does). 330 3314.3.1.3 Specific requirements to the number of MSI-X interrupts 332 333As noted above, there could be devices that can not operate with just any 334number of MSI-X interrupts within a range. E.g., let's assume a device that 335is only capable sending the number of MSI-X interrupts which is a power of 336two. A routine that enables MSI-X mode for such device might look like this: 337 338/* 339 * Assume 'minvec' and 'maxvec' are non-zero 340 */ 341static int foo_driver_enable_msix(struct foo_adapter *adapter, 342 int minvec, int maxvec) 343{ 344 int rc; 345 346 minvec = roundup_pow_of_two(minvec); 347 maxvec = rounddown_pow_of_two(maxvec); 348 349 if (minvec > maxvec) 350 return -ERANGE; 351 352retry: 353 rc = pci_enable_msix_range(adapter->pdev, adapter->msix_entries, 354 maxvec, maxvec); 355 /* 356 * -ENOSPC is the only error code allowed to be analyzed 357 */ 358 if (rc == -ENOSPC) { 359 if (maxvec == 1) 360 return -ENOSPC; 361 362 maxvec /= 2; 363 364 if (minvec > maxvec) 365 return -ENOSPC; 366 367 goto retry; 368 } 369 370 return rc; 371} 372 373Note how pci_enable_msix_range() return value is analyzed for a fallback - 374any error code other than -ENOSPC indicates a fatal error and should not 375be retried. 376 3774.3.2 pci_enable_msix_exact 378 379int pci_enable_msix_exact(struct pci_dev *dev, 380 struct msix_entry *entries, int nvec) 381 382This variation on pci_enable_msix_range() call allows a device driver to 383request exactly 'nvec' MSI-Xs. 384 385If this function returns a negative number, it indicates an error and 386the driver should not attempt to allocate any more MSI-X interrupts for 387this device. 388 389By contrast with pci_enable_msix_range() function, pci_enable_msix_exact() 390returns zero in case of success, which indicates MSI-X interrupts have been 391successfully allocated. 392 393Another version of a routine that enables MSI-X mode for a device with 394specific requirements described in chapter 4.3.1.3 might look like this: 395 396/* 397 * Assume 'minvec' and 'maxvec' are non-zero 398 */ 399static int foo_driver_enable_msix(struct foo_adapter *adapter, 400 int minvec, int maxvec) 401{ 402 int rc; 403 404 minvec = roundup_pow_of_two(minvec); 405 maxvec = rounddown_pow_of_two(maxvec); 406 407 if (minvec > maxvec) 408 return -ERANGE; 409 410retry: 411 rc = pci_enable_msix_exact(adapter->pdev, 412 adapter->msix_entries, maxvec); 413 414 /* 415 * -ENOSPC is the only error code allowed to be analyzed 416 */ 417 if (rc == -ENOSPC) { 418 if (maxvec == 1) 419 return -ENOSPC; 420 421 maxvec /= 2; 422 423 if (minvec > maxvec) 424 return -ENOSPC; 425 426 goto retry; 427 } else if (rc < 0) { 428 return rc; 429 } 430 431 return maxvec; 432} 433 4344.3.3 pci_disable_msix 435 436void pci_disable_msix(struct pci_dev *dev) 437 438This function should be used to undo the effect of pci_enable_msix_range(). 439It frees the previously allocated MSI-X interrupts. The interrupts may 440subsequently be assigned to another device, so drivers should not cache 441the value of the 'vector' elements over a call to pci_disable_msix(). 442 443Before calling this function, a device driver must always call free_irq() 444on any interrupt for which it previously called request_irq(). 445Failure to do so results in a BUG_ON(), leaving the device with 446MSI-X enabled and thus leaking its vector. 447 4484.3.3 The MSI-X Table 449 450The MSI-X capability specifies a BAR and offset within that BAR for the 451MSI-X Table. This address is mapped by the PCI subsystem, and should not 452be accessed directly by the device driver. If the driver wishes to 453mask or unmask an interrupt, it should call disable_irq() / enable_irq(). 454 4554.3.4 pci_msix_vec_count 456 457int pci_msix_vec_count(struct pci_dev *dev) 458 459This function could be used to retrieve number of entries in the device 460MSI-X table. 461 462If this function returns a negative number, it indicates the device is 463not capable of sending MSI-Xs. 464 465If this function returns a positive number, it indicates the maximum 466number of MSI-X interrupt vectors that could be allocated. 467 4684.4 Handling devices implementing both MSI and MSI-X capabilities 469 470If a device implements both MSI and MSI-X capabilities, it can 471run in either MSI mode or MSI-X mode, but not both simultaneously. 472This is a requirement of the PCI spec, and it is enforced by the 473PCI layer. Calling pci_enable_msi_range() when MSI-X is already 474enabled or pci_enable_msix_range() when MSI is already enabled 475results in an error. If a device driver wishes to switch between MSI 476and MSI-X at runtime, it must first quiesce the device, then switch 477it back to pin-interrupt mode, before calling pci_enable_msi_range() 478or pci_enable_msix_range() and resuming operation. This is not expected 479to be a common operation but may be useful for debugging or testing 480during development. 481 4824.5 Considerations when using MSIs 483 4844.5.1 Choosing between MSI-X and MSI 485 486If your device supports both MSI-X and MSI capabilities, you should use 487the MSI-X facilities in preference to the MSI facilities. As mentioned 488above, MSI-X supports any number of interrupts between 1 and 2048. 489In contrast, MSI is restricted to a maximum of 32 interrupts (and 490must be a power of two). In addition, the MSI interrupt vectors must 491be allocated consecutively, so the system might not be able to allocate 492as many vectors for MSI as it could for MSI-X. On some platforms, MSI 493interrupts must all be targeted at the same set of CPUs whereas MSI-X 494interrupts can all be targeted at different CPUs. 495 4964.5.2 Spinlocks 497 498Most device drivers have a per-device spinlock which is taken in the 499interrupt handler. With pin-based interrupts or a single MSI, it is not 500necessary to disable interrupts (Linux guarantees the same interrupt will 501not be re-entered). If a device uses multiple interrupts, the driver 502must disable interrupts while the lock is held. If the device sends 503a different interrupt, the driver will deadlock trying to recursively 504acquire the spinlock. Such deadlocks can be avoided by using 505spin_lock_irqsave() or spin_lock_irq() which disable local interrupts 506and acquire the lock (see Documentation/DocBook/kernel-locking). 507 5084.6 How to tell whether MSI/MSI-X is enabled on a device 509 510Using 'lspci -v' (as root) may show some devices with "MSI", "Message 511Signalled Interrupts" or "MSI-X" capabilities. Each of these capabilities 512has an 'Enable' flag which is followed with either "+" (enabled) 513or "-" (disabled). 514 515 5165. MSI quirks 517 518Several PCI chipsets or devices are known not to support MSIs. 519The PCI stack provides three ways to disable MSIs: 520 5211. globally 5222. on all devices behind a specific bridge 5233. on a single device 524 5255.1. Disabling MSIs globally 526 527Some host chipsets simply don't support MSIs properly. If we're 528lucky, the manufacturer knows this and has indicated it in the ACPI 529FADT table. In this case, Linux automatically disables MSIs. 530Some boards don't include this information in the table and so we have 531to detect them ourselves. The complete list of these is found near the 532quirk_disable_all_msi() function in drivers/pci/quirks.c. 533 534If you have a board which has problems with MSIs, you can pass pci=nomsi 535on the kernel command line to disable MSIs on all devices. It would be 536in your best interests to report the problem to linux-pci@vger.kernel.org 537including a full 'lspci -v' so we can add the quirks to the kernel. 538 5395.2. Disabling MSIs below a bridge 540 541Some PCI bridges are not able to route MSIs between busses properly. 542In this case, MSIs must be disabled on all devices behind the bridge. 543 544Some bridges allow you to enable MSIs by changing some bits in their 545PCI configuration space (especially the Hypertransport chipsets such 546as the nVidia nForce and Serverworks HT2000). As with host chipsets, 547Linux mostly knows about them and automatically enables MSIs if it can. 548If you have a bridge unknown to Linux, you can enable 549MSIs in configuration space using whatever method you know works, then 550enable MSIs on that bridge by doing: 551 552 echo 1 > /sys/bus/pci/devices/$bridge/msi_bus 553 554where $bridge is the PCI address of the bridge you've enabled (eg 5550000:00:0e.0). 556 557To disable MSIs, echo 0 instead of 1. Changing this value should be 558done with caution as it could break interrupt handling for all devices 559below this bridge. 560 561Again, please notify linux-pci@vger.kernel.org of any bridges that need 562special handling. 563 5645.3. Disabling MSIs on a single device 565 566Some devices are known to have faulty MSI implementations. Usually this 567is handled in the individual device driver, but occasionally it's necessary 568to handle this with a quirk. Some drivers have an option to disable use 569of MSI. While this is a convenient workaround for the driver author, 570it is not good practice, and should not be emulated. 571 5725.4. Finding why MSIs are disabled on a device 573 574From the above three sections, you can see that there are many reasons 575why MSIs may not be enabled for a given device. Your first step should 576be to examine your dmesg carefully to determine whether MSIs are enabled 577for your machine. You should also check your .config to be sure you 578have enabled CONFIG_PCI_MSI. 579 580Then, 'lspci -t' gives the list of bridges above a device. Reading 581/sys/bus/pci/devices/*/msi_bus will tell you whether MSIs are enabled (1) 582or disabled (0). If 0 is found in any of the msi_bus files belonging 583to bridges between the PCI root and the device, MSIs are disabled. 584 585It is also worth checking the device driver to see whether it supports MSIs. 586For example, it may contain calls to pci_enable_msi_range() or 587pci_enable_msix_range(). 588