linux/Documentation/PCI/MSI-HOWTO.txt
<<
>>
Prefs
   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_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 is
 115less than 'count' and indicates the number of interrupts that could have
 116been allocated.  In neither case is the irq value updated or the device
 117switched 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 requested.
 121For instance, the driver could still make use of fewer interrupts;
 122in 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()
 127returns 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
 140Before calling this function, a device driver must always call free_irq()
 141on any interrupt for which it previously called request_irq().
 142Failure to do so results in a BUG_ON(), leaving the device with
 143MSI enabled and thus leaking 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 yet allocate only a
 159two-element array.  The driver is expected to fill in the 'entry' value
 160in each element of the array to indicate for which entries the kernel
 161should assign interrupts; 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
 171device is switched into MSI-X mode and the function returns 0.
 172The 'vector' member in each entry is populated with the interrupt number;
 173the driver should then call request_irq() for each 'vector' that it
 174decides to use.  The device driver is responsible for keeping track of the
 175interrupts assigned to the MSI-X vectors so it can free them again later.
 176
 177If this function returns a negative number, it indicates an error and
 178the driver should not attempt to allocate any more MSI-X interrupts for
 179this device.  If it returns a positive number, it indicates the maximum
 180number of interrupt vectors that could have been allocated. See example
 181below.
 182
 183This function, in contrast with pci_enable_msi(), does not adjust
 184dev->irq.  The device will not generate interrupts for this interrupt
 185number once MSI-X is enabled.
 186
 187Device drivers should normally call this function once per device
 188during the initialization phase.
 189
 190It is ideal if drivers can cope with a variable number of MSI-X interrupts;
 191there are many reasons why the platform may not be able to provide the
 192exact number that a driver asks for.
 193
 194A request loop to achieve that might look like:
 195
 196static int foo_driver_enable_msix(struct foo_adapter *adapter, int nvec)
 197{
 198        while (nvec >= FOO_DRIVER_MINIMUM_NVEC) {
 199                rc = pci_enable_msix(adapter->pdev,
 200                                     adapter->msix_entries, nvec);
 201                if (rc > 0)
 202                        nvec = rc;
 203                else
 204                        return rc;
 205        }
 206
 207        return -ENOSPC;
 208}
 209
 2104.3.2 pci_disable_msix
 211
 212void pci_disable_msix(struct pci_dev *dev)
 213
 214This function should be used to undo the effect of pci_enable_msix().  It frees
 215the previously allocated message signaled interrupts.  The interrupts may
 216subsequently be assigned to another device, so drivers should not cache
 217the value of the 'vector' elements over a call to pci_disable_msix().
 218
 219Before calling this function, a device driver must always call free_irq()
 220on any interrupt for which it previously called request_irq().
 221Failure to do so results in a BUG_ON(), leaving the device with
 222MSI-X enabled and thus leaking its vector.
 223
 2244.3.3 The MSI-X Table
 225
 226The MSI-X capability specifies a BAR and offset within that BAR for the
 227MSI-X Table.  This address is mapped by the PCI subsystem, and should not
 228be accessed directly by the device driver.  If the driver wishes to
 229mask or unmask an interrupt, it should call disable_irq() / enable_irq().
 230
 2314.4 Handling devices implementing both MSI and MSI-X capabilities
 232
 233If a device implements both MSI and MSI-X capabilities, it can
 234run in either MSI mode or MSI-X mode, but not both simultaneously.
 235This is a requirement of the PCI spec, and it is enforced by the
 236PCI layer.  Calling pci_enable_msi() when MSI-X is already enabled or
 237pci_enable_msix() when MSI is already enabled results in an error.
 238If a device driver wishes to switch between MSI and MSI-X at runtime,
 239it must first quiesce the device, then switch it back to pin-interrupt
 240mode, before calling pci_enable_msi() or pci_enable_msix() and resuming
 241operation.  This is not expected to be a common operation but may be
 242useful for debugging or testing during development.
 243
 2444.5 Considerations when using MSIs
 245
 2464.5.1 Choosing between MSI-X and MSI
 247
 248If your device supports both MSI-X and MSI capabilities, you should use
 249the MSI-X facilities in preference to the MSI facilities.  As mentioned
 250above, MSI-X supports any number of interrupts between 1 and 2048.
 251In constrast, MSI is restricted to a maximum of 32 interrupts (and
 252must be a power of two).  In addition, the MSI interrupt vectors must
 253be allocated consecutively, so the system might not be able to allocate
 254as many vectors for MSI as it could for MSI-X.  On some platforms, MSI
 255interrupts must all be targeted at the same set of CPUs whereas MSI-X
 256interrupts can all be targeted at different CPUs.
 257
 2584.5.2 Spinlocks
 259
 260Most device drivers have a per-device spinlock which is taken in the
 261interrupt handler.  With pin-based interrupts or a single MSI, it is not
 262necessary to disable interrupts (Linux guarantees the same interrupt will
 263not be re-entered).  If a device uses multiple interrupts, the driver
 264must disable interrupts while the lock is held.  If the device sends
 265a different interrupt, the driver will deadlock trying to recursively
 266acquire the spinlock.
 267
 268There are two solutions.  The first is to take the lock with
 269spin_lock_irqsave() or spin_lock_irq() (see
 270Documentation/DocBook/kernel-locking).  The second is to specify
 271IRQF_DISABLED to request_irq() so that the kernel runs the entire
 272interrupt routine with interrupts disabled.
 273
 274If your MSI interrupt routine does not hold the lock for the whole time
 275it is running, the first solution may be best.  The second solution is
 276normally preferred as it avoids making two transitions from interrupt
 277disabled to enabled and back again.
 278
 2794.6 How to tell whether MSI/MSI-X is enabled on a device
 280
 281Using 'lspci -v' (as root) may show some devices with "MSI", "Message
 282Signalled Interrupts" or "MSI-X" capabilities.  Each of these capabilities
 283has an 'Enable' flag which is followed with either "+" (enabled)
 284or "-" (disabled).
 285
 286
 2875. MSI quirks
 288
 289Several PCI chipsets or devices are known not to support MSIs.
 290The PCI stack provides three ways to disable MSIs:
 291
 2921. globally
 2932. on all devices behind a specific bridge
 2943. on a single device
 295
 2965.1. Disabling MSIs globally
 297
 298Some host chipsets simply don't support MSIs properly.  If we're
 299lucky, the manufacturer knows this and has indicated it in the ACPI
 300FADT table.  In this case, Linux automatically disables MSIs.
 301Some boards don't include this information in the table and so we have
 302to detect them ourselves.  The complete list of these is found near the
 303quirk_disable_all_msi() function in drivers/pci/quirks.c.
 304
 305If you have a board which has problems with MSIs, you can pass pci=nomsi
 306on the kernel command line to disable MSIs on all devices.  It would be
 307in your best interests to report the problem to linux-pci@vger.kernel.org
 308including a full 'lspci -v' so we can add the quirks to the kernel.
 309
 3105.2. Disabling MSIs below a bridge
 311
 312Some PCI bridges are not able to route MSIs between busses properly.
 313In this case, MSIs must be disabled on all devices behind the bridge.
 314
 315Some bridges allow you to enable MSIs by changing some bits in their
 316PCI configuration space (especially the Hypertransport chipsets such
 317as the nVidia nForce and Serverworks HT2000).  As with host chipsets,
 318Linux mostly knows about them and automatically enables MSIs if it can.
 319If you have a bridge unknown to Linux, you can enable
 320MSIs in configuration space using whatever method you know works, then
 321enable MSIs on that bridge by doing:
 322
 323       echo 1 > /sys/bus/pci/devices/$bridge/msi_bus
 324
 325where $bridge is the PCI address of the bridge you've enabled (eg
 3260000:00:0e.0).
 327
 328To disable MSIs, echo 0 instead of 1.  Changing this value should be
 329done with caution as it could break interrupt handling for all devices
 330below this bridge.
 331
 332Again, please notify linux-pci@vger.kernel.org of any bridges that need
 333special handling.
 334
 3355.3. Disabling MSIs on a single device
 336
 337Some devices are known to have faulty MSI implementations.  Usually this
 338is handled in the individual device driver, but occasionally it's necessary
 339to handle this with a quirk.  Some drivers have an option to disable use
 340of MSI.  While this is a convenient workaround for the driver author,
 341it is not good practise, and should not be emulated.
 342
 3435.4. Finding why MSIs are disabled on a device
 344
 345From the above three sections, you can see that there are many reasons
 346why MSIs may not be enabled for a given device.  Your first step should
 347be to examine your dmesg carefully to determine whether MSIs are enabled
 348for your machine.  You should also check your .config to be sure you
 349have enabled CONFIG_PCI_MSI.
 350
 351Then, 'lspci -t' gives the list of bridges above a device.  Reading
 352/sys/bus/pci/devices/*/msi_bus will tell you whether MSIs are enabled (1)
 353or disabled (0).  If 0 is found in any of the msi_bus files belonging
 354to bridges between the PCI root and the device, MSIs are disabled.
 355
 356It is also worth checking the device driver to see whether it supports MSIs.
 357For example, it may contain calls to pci_enable_msi(), pci_enable_msix() or
 358pci_enable_msi_block().
 359
lxr.linux.no kindly hosted by Redpill Linpro AS, provider of Linux consulting and operations services since 1995.