diff options
author | Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> | 2010-10-18 10:49:10 -0400 |
---|---|---|
committer | Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> | 2010-10-18 10:49:10 -0400 |
commit | 3a69e9165a271b026c7149886b96ab0cc2e9a36b (patch) | |
tree | 9a51f952039745feee23d21b3b6b3834aabeef0c /drivers/xen | |
parent | 3b32f574a032bb5c93957317bd4ce5c3397d5a7b (diff) |
xen: Find an unbound irq number in reverse order (high to low).
In earlier Xen Linux kernels, the IRQ mapping was a straight 1:1 and the
find_unbound_irq started looking around 256 for open IRQs and up. IRQs
from 0 to 255 were reserved for PCI devices. Previous to this patch,
the 'find_unbound_irq' started looking at get_nr_hw_irqs() number.
For privileged domain where the ACPI information is available that
returns the upper-bound of what the GSIs. For non-privileged PV domains,
where ACPI is no-existent the get_nr_hw_irqs() reports the IRQ_LEGACY (16).
With PCI passthrough enabled, and with PCI cards that have IRQs pinned
to a higher number than 16 we collide with previously allocated IRQs.
Specifically the PCI IRQs collide with the IPI's for Xen functions
(as they are allocated earlier).
For example:
00:00.11 USB Controller: ATI Technologies Inc SB700 USB OHCI1 Controller (prog-if 10 [OHCI])
...
Interrupt: pin A routed to IRQ 18
[root@localhost ~]# cat /proc/interrupts | head
CPU0 CPU1 CPU2
16: 38186 0 0 xen-dyn-virq timer0
17: 149 0 0 xen-dyn-ipi spinlock0
18: 962 0 0 xen-dyn-ipi resched0
and when the USB controller is loaded, the kernel reports:
IRQ handler type mismatch for IRQ 18
current handler: resched0
One way to fix this is to reverse the logic when looking for un-used
IRQ numbers and start with the highest available number. With that,
we would get:
CPU0 CPU1 CPU2
... snip ..
292: 35 0 0 xen-dyn-ipi callfunc0
293: 3992 0 0 xen-dyn-ipi resched0
294: 224 0 0 xen-dyn-ipi spinlock0
295: 57183 0 0 xen-dyn-virq timer0
NMI: 0 0 0 Non-maskable interrupts
.. snip ..
And interrupts for PCI cards are now accessible.
This patch also includes the fix, found by Ian Campbell, titled
"xen: fix off-by-one error in find_unbound_irq."
[v2: Added an explanation in the code]
[v3: Rebased on top of tip/irq/core]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Diffstat (limited to 'drivers/xen')
-rw-r--r-- | drivers/xen/events.c | 25 |
1 files changed, 20 insertions, 5 deletions
diff --git a/drivers/xen/events.c b/drivers/xen/events.c index 1e39908d02f9..bab5ac18fe0e 100644 --- a/drivers/xen/events.c +++ b/drivers/xen/events.c | |||
@@ -368,8 +368,13 @@ static int find_unbound_irq(void) | |||
368 | { | 368 | { |
369 | struct irq_data *data; | 369 | struct irq_data *data; |
370 | int irq, res; | 370 | int irq, res; |
371 | int start = get_nr_hw_irqs(); | ||
371 | 372 | ||
372 | for (irq = 0; irq < nr_irqs; irq++) { | 373 | if (start == nr_irqs) |
374 | goto no_irqs; | ||
375 | |||
376 | /* nr_irqs is a magic value. Must not use it.*/ | ||
377 | for (irq = nr_irqs-1; irq > start; irq--) { | ||
373 | data = irq_get_irq_data(irq); | 378 | data = irq_get_irq_data(irq); |
374 | /* only 0->15 have init'd desc; handle irq > 16 */ | 379 | /* only 0->15 have init'd desc; handle irq > 16 */ |
375 | if (!data) | 380 | if (!data) |
@@ -382,8 +387,8 @@ static int find_unbound_irq(void) | |||
382 | return irq; | 387 | return irq; |
383 | } | 388 | } |
384 | 389 | ||
385 | if (irq == nr_irqs) | 390 | if (irq == start) |
386 | panic("No available IRQ to bind to: increase nr_irqs!\n"); | 391 | goto no_irqs; |
387 | 392 | ||
388 | res = irq_alloc_desc_at(irq, 0); | 393 | res = irq_alloc_desc_at(irq, 0); |
389 | 394 | ||
@@ -391,6 +396,9 @@ static int find_unbound_irq(void) | |||
391 | return -1; | 396 | return -1; |
392 | 397 | ||
393 | return irq; | 398 | return irq; |
399 | |||
400 | no_irqs: | ||
401 | panic("No available IRQ to bind to: increase nr_irqs!\n"); | ||
394 | } | 402 | } |
395 | 403 | ||
396 | static bool identity_mapped_irq(unsigned irq) | 404 | static bool identity_mapped_irq(unsigned irq) |
@@ -544,8 +552,15 @@ static int find_irq_by_gsi(unsigned gsi) | |||
544 | return -1; | 552 | return -1; |
545 | } | 553 | } |
546 | 554 | ||
547 | /* | 555 | /* xen_allocate_irq might allocate irqs from the top down, as a |
548 | * Allocate a physical irq, along with a vector. We don't assign an | 556 | * consequence don't assume that the irq number returned has a low value |
557 | * or can be used as a pirq number unless you know otherwise. | ||
558 | * | ||
559 | * One notable exception is when xen_allocate_irq is called passing an | ||
560 | * hardware gsi as argument, in that case the irq number returned | ||
561 | * matches the gsi number passed as first argument. | ||
562 | |||
563 | * Note: We don't assign an | ||
549 | * event channel until the irq actually started up. Return an | 564 | * event channel until the irq actually started up. Return an |
550 | * existing irq if we've already got one for the gsi. | 565 | * existing irq if we've already got one for the gsi. |
551 | */ | 566 | */ |