About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / PCI / MSI-HOWTO.txt




Custom Search

Based on kernel version 3.13. Page generated on 2014-01-20 22:04 EST.

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

Information is copyright its respective author. All material is available from the Linux Kernel Source distributed under a GPL License. This page is provided as a free service by mjmwired.net.