thr3ads.net - Xen devel - [Xen-devel] [PATCH] linux: prevent invalid or unsupportable PIRQs from being used [Nov 2008]

If this information is useful, please help other people find it:
Share via:

Jan Beulich

2008-Nov-05 14:13 UTC

[Xen-devel] [PATCH] linux: prevent invalid or unsupportable PIRQs from being used

By keeping the respective irq_desc[] entries pointing to no_irq_type,
setup_irq() (and thus request_irq()) will fail for such IRQs. This
matches native behavior, which also only installs ioapic_*_type out of
ioapic_register_intr().

At the same time, make assign_irq_vector() fail not only when Xen
doesn''t support the PIRQ, but also if the IRQ requested
doesn''t fall
in the kernel''s PIRQ space.

As usual, written and tested on 2.6.27.4 and made apply to the 2.6.18
tree without further testing.

Signed-off-by: Jan Beulich <jbeulich@novell.com>

Index: head-2008-11-04/arch/i386/kernel/io_apic-xen.c
==================================================================---
head-2008-11-04.orig/arch/i386/kernel/io_apic-xen.c	2008-11-04
13:45:24.000000000 +0100
+++ head-2008-11-04/arch/i386/kernel/io_apic-xen.c	2008-11-05 12:09:47.000000000
+0100
@@ -1229,6 +1229,9 @@ static int __assign_irq_vector(int irq)
 
 	BUG_ON(irq != AUTO_ASSIGN && (unsigned)irq >= NR_IRQ_VECTORS);
 
+	if (irq < PIRQ_BASE || irq - PIRQ_BASE > NR_PIRQS)
+		return -EINVAL;
+
 	spin_lock_irqsave(&vector_lock, flags);
 
 	if (irq != AUTO_ASSIGN && IO_APIC_VECTOR(irq) > 0) {
Index: head-2008-11-04/arch/x86_64/kernel/io_apic-xen.c
==================================================================---
head-2008-11-04.orig/arch/x86_64/kernel/io_apic-xen.c	2008-11-04
13:45:24.000000000 +0100
+++ head-2008-11-04/arch/x86_64/kernel/io_apic-xen.c	2008-11-05
12:10:12.000000000 +0100
@@ -855,6 +855,9 @@ static int __assign_irq_vector(int irq, 
   
   	BUG_ON(irq != AUTO_ASSIGN && (unsigned)irq >= NR_IRQ_VECTORS);
 
+	if (irq < PIRQ_BASE || irq - PIRQ_BASE > NR_PIRQS)
+		return -EINVAL;
+
 	spin_lock_irqsave(&vector_lock, flags);
 
   	if (irq != AUTO_ASSIGN && IO_APIC_VECTOR(irq) > 0) {
Index: head-2008-11-04/drivers/xen/core/evtchn.c
==================================================================---
head-2008-11-04.orig/drivers/xen/core/evtchn.c	2008-10-29 11:35:18.000000000
+0100
+++ head-2008-11-04/drivers/xen/core/evtchn.c	2008-11-05 13:56:23.000000000
+0100
@@ -784,71 +784,6 @@ static struct irq_chip dynirq_chip = {
 	.retrigger = resend_irq_on_evtchn,
 };
 
-void evtchn_register_pirq(int irq)
-{
-	struct irq_desc *desc;
-	unsigned long flags;
-
-	irq_info[irq] = mk_irq_info(IRQT_PIRQ, irq, 0);
-
-	/* Cannot call set_irq_probe(), as that''s marked __init. */
-	desc = irq_desc + irq;
-	spin_lock_irqsave(&desc->lock, flags);
-	desc->status &= ~IRQ_NOPROBE;
-	spin_unlock_irqrestore(&desc->lock, flags);
-}
-
-#if defined(CONFIG_X86_IO_APIC)
-#define identity_mapped_irq(irq) (!IO_APIC_IRQ((irq) - PIRQ_BASE))
-#elif defined(CONFIG_X86)
-#define identity_mapped_irq(irq) (((irq) - PIRQ_BASE) < 16)
-#else
-#define identity_mapped_irq(irq) (1)
-#endif
-
-int evtchn_map_pirq(int irq, int xen_pirq)
-{
-	if (irq < 0) {
-		static DEFINE_SPINLOCK(irq_alloc_lock);
-
-		irq = PIRQ_BASE + NR_PIRQS - 1;
-		spin_lock(&irq_alloc_lock);
-		do {
-			if (identity_mapped_irq(irq))
-				continue;
-			if (!index_from_irq(irq)) {
-				BUG_ON(type_from_irq(irq) != IRQT_UNBOUND);
-				irq_info[irq] = mk_irq_info(IRQT_PIRQ,
-							    xen_pirq, 0);
-				break;
-			}
-		} while (--irq >= PIRQ_BASE);
-		spin_unlock(&irq_alloc_lock);
-		if (irq < PIRQ_BASE)
-			return -ENOSPC;
-	} else if (!xen_pirq) {
-		if (unlikely(type_from_irq(irq) != IRQT_PIRQ))
-			return -EINVAL;
-		irq_info[irq] = IRQ_UNBOUND;
-		return 0;
-	} else if (type_from_irq(irq) != IRQT_PIRQ
-		   || index_from_irq(irq) != xen_pirq) {
-		printk(KERN_ERR "IRQ#%d is already mapped to %d:%u - "
-				"cannot map to PIRQ#%u\n",
-		       irq, type_from_irq(irq), index_from_irq(irq), xen_pirq);
-		return -EINVAL;
-	}
-	return index_from_irq(irq) ? irq : -EINVAL;
-}
-
-int evtchn_get_xen_pirq(int irq)
-{
-	if (identity_mapped_irq(irq))
-		return irq;
-	BUG_ON(type_from_irq(irq) != IRQT_PIRQ);
-	return index_from_irq(irq);
-}
-
 static inline void pirq_unmask_notify(int irq)
 {
 	struct physdev_eoi eoi = { .irq = evtchn_get_xen_pirq(irq) };
@@ -1161,6 +1096,68 @@ void irq_resume(void)
 
 }
 
+#if defined(CONFIG_X86_IO_APIC)
+#define identity_mapped_irq(irq) (!IO_APIC_IRQ((irq) - PIRQ_BASE))
+#elif defined(CONFIG_X86)
+#define identity_mapped_irq(irq) (((irq) - PIRQ_BASE) < 16)
+#else
+#define identity_mapped_irq(irq) (1)
+#endif
+
+void evtchn_register_pirq(int irq)
+{
+	BUG_ON(irq < PIRQ_BASE || irq - PIRQ_BASE > NR_PIRQS);
+	if (identity_mapped_irq(irq))
+		return;
+	irq_info[irq] = mk_irq_info(IRQT_PIRQ, irq, 0);
+	set_irq_chip_and_handler_name(irq, &pirq_chip, handle_level_irq,
"level");
+}
+
+int evtchn_map_pirq(int irq, int xen_pirq)
+{
+	if (irq < 0) {
+		static DEFINE_SPINLOCK(irq_alloc_lock);
+
+		irq = PIRQ_BASE + NR_PIRQS - 1;
+		spin_lock(&irq_alloc_lock);
+		do {
+			if (identity_mapped_irq(irq))
+				continue;
+			if (!index_from_irq(irq)) {
+				BUG_ON(type_from_irq(irq) != IRQT_UNBOUND);
+				irq_info[irq] = mk_irq_info(IRQT_PIRQ,
+							    xen_pirq, 0);
+				break;
+			}
+		} while (--irq >= PIRQ_BASE);
+		spin_unlock(&irq_alloc_lock);
+		if (irq < PIRQ_BASE)
+			return -ENOSPC;
+		irq_desc[irq].chip = &pirq_type;
+	} else if (!xen_pirq) {
+		if (unlikely(type_from_irq(irq) != IRQT_PIRQ))
+			return -EINVAL;
+		irq_desc[irq].chip = &no_irq_type;
+		irq_info[irq] = IRQ_UNBOUND;
+		return 0;
+	} else if (type_from_irq(irq) != IRQT_PIRQ
+		   || index_from_irq(irq) != xen_pirq) {
+		printk(KERN_ERR "IRQ#%d is already mapped to %d:%u - "
+				"cannot map to PIRQ#%u\n",
+		       irq, type_from_irq(irq), index_from_irq(irq), xen_pirq);
+		return -EINVAL;
+	}
+	return index_from_irq(irq) ? irq : -EINVAL;
+}
+
+int evtchn_get_xen_pirq(int irq)
+{
+	if (identity_mapped_irq(irq))
+		return irq;
+	BUG_ON(type_from_irq(irq) != IRQT_PIRQ);
+	return index_from_irq(irq);
+}
+
 void __init xen_init_IRQ(void)
 {
 	unsigned int i;
@@ -1197,16 +1195,16 @@ void __init xen_init_IRQ(void)
 	for (i = PIRQ_BASE; i < (PIRQ_BASE + NR_PIRQS); i++) {
 		irq_bindcount[i] = 1;
 
+		if (!identity_mapped_irq(i))
+			continue;
+
 #ifdef RTC_IRQ
 		/* If not domain 0, force our RTC driver to fail its probe. */
-		if (identity_mapped_irq(i) && ((i - PIRQ_BASE) == RTC_IRQ)
-		    && !is_initial_xendomain())
+		if (i - PIRQ_BASE == RTC_IRQ && !is_initial_xendomain())
 			continue;
 #endif
 
 		irq_desc[i].status = IRQ_DISABLED;
-		if (!identity_mapped_irq(i))
-			irq_desc[i].status |= IRQ_NOPROBE;
 		irq_desc[i].action = NULL;
 		irq_desc[i].depth = 1;
 		irq_desc[i].chip = &pirq_type;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser

2008-Nov-05 14:54 UTC

head link

Re: [Xen-devel] [PATCH] linux: prevent invalid or unsupportable PIRQs from being used

On 5/11/08 14:13, "Jan Beulich" <jbeulich@novell.com> wrote:
> By keeping the respective irq_desc[] entries pointing to no_irq_type,
> setup_irq() (and thus request_irq()) will fail for such IRQs. This
> matches native behavior, which also only installs ioapic_*_type out of
> ioapic_register_intr().
> 
> At the same time, make assign_irq_vector() fail not only when Xen
> doesn''t support the PIRQ, but also if the IRQ requested
doesn''t fall
> in the kernel''s PIRQ space.
Reverted as it breaks the build non-trivially (at least: no
set_irq_chip_and_handler_name(); no pirq_chip structure). The 2.6.18
isn''t
really the place for big code restructurings anyway (this was a big patch).

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Jan Beulich

2008-Nov-05 15:20 UTC

head link

Re: [Xen-devel] [PATCH] linux: prevent invalid or unsupportable PIRQsfrom being used

>>> "Jan Beulich" <jbeulich@novell.com> 05.11.08 15:13
>>>
>By keeping the respective irq_desc[] entries pointing to no_irq_type,
>setup_irq() (and thus request_irq()) will fail for such IRQs. This
>matches native behavior, which also only installs ioapic_*_type out of
>ioapic_register_intr().
>
>At the same time, make assign_irq_vector() fail not only when Xen
>doesn''t support the PIRQ, but also if the IRQ requested
doesn''t fall
>in the kernel''s PIRQ space.
I wrote this in response to a bug report from IBM where on a 4-node box
they would see crashes when trying to request_irq() with an irq greater
or equal to 256 (the box has 387 GSIs). The patch is assumed to fix that
crash, but of course any device at this high an IRQ (and even at ones
slightly below 256, in case MSI took up some of them) will not work, due
to Xen refusing to map a vector for it.

Clearly, growing NR_IRQS will be necessary here, perhaps based on
Linux'' x86-64 scheme of assigning IRQs and their vectors on a per-CPU
basis. Are there any plans in that direction?

Jan

P.S. The good news from that report from IBM is that they were able to
bring up 96 processors.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser

2008-Nov-05 15:26 UTC

head link

Re: [Xen-devel] [PATCH] linux: prevent invalid or unsupportable PIRQsfrom being used

On 5/11/08 15:20, "Jan Beulich" <jbeulich@novell.com> wrote:
> Clearly, growing NR_IRQS will be necessary here, perhaps based on
> Linux'' x86-64 scheme of assigning IRQs and their vectors on a
per-CPU
> basis. Are there any plans in that direction?
Not for 2.6.18. Perhaps for pv_ops, if latest kernels don''t have such
functionality already. Remember we''re obsoleting the 2.6.18 tree before
Xen
3.4, assuming Jeremy gets the dom0 stuff worked out by then (and
there''s no
reason to think he won''t).

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Jan Beulich

2008-Nov-05 15:27 UTC

head link

Re: [Xen-devel] [PATCH] linux: prevent invalid or unsupportablePIRQs from being used

>>> Keir Fraser <keir.fraser@eu.citrix.com> 05.11.08 15:54
>>>
>On 5/11/08 14:13, "Jan Beulich" <jbeulich@novell.com> wrote:
>
>> By keeping the respective irq_desc[] entries pointing to no_irq_type,
>> setup_irq() (and thus request_irq()) will fail for such IRQs. This
>> matches native behavior, which also only installs ioapic_*_type out of
>> ioapic_register_intr().
>> 
>> At the same time, make assign_irq_vector() fail not only when Xen
>> doesn''t support the PIRQ, but also if the IRQ requested
doesn''t fall
>> in the kernel''s PIRQ space.
>
>Reverted as it breaks the build non-trivially (at least: no
>set_irq_chip_and_handler_name(); no pirq_chip structure). The 2.6.18
isn''t
>really the place for big code restructurings anyway (this was a big patch).
The size of the patch only comes from moving some code down in evtchn.c
(in an attempt to avoid forward declarations). The actual changes
aren''t
that big, and from what you write I conclude I just messed up a single line
(or better - forgot to convert it down to 2.6.18 terms) - I''m sorry for
that.
Below is a fixed patch, in case you want to give this another try.

The point of sending the patch is that it fixes a bug you''d certainly
also
see in that tree (see my other follow-up mail). Plus it puts on more
consistent feet the suppressing of undue auto-probing - the first solution
to this was somewhat hackish in my opinion.

Jan

*******************************************************

By keeping the respective irq_desc[] entries pointing to no_irq_type,
setup_irq() (and thus request_irq()) will fail for such IRQs. This
matches native behavior, which also only installs ioapic_*_type out of
ioapic_register_intr().

At the same time, make assign_irq_vector() fail not only when Xen
doesn''t support the PIRQ, but also if the IRQ requested
doesn''t fall
in the kernel''s PIRQ space.

As usual, written and tested on 2.6.27.4 and made apply to the 2.6.18
tree without further testing.

Signed-off-by: Jan Beulich <jbeulich@novell.com>

Index: head-2008-11-04/arch/i386/kernel/io_apic-xen.c
==================================================================---
head-2008-11-04.orig/arch/i386/kernel/io_apic-xen.c	2008-11-04
13:45:24.000000000 +0100
+++ head-2008-11-04/arch/i386/kernel/io_apic-xen.c	2008-11-05 12:09:47.000000000
+0100
@@ -1229,6 +1229,9 @@ static int __assign_irq_vector(int irq)
 
 	BUG_ON(irq != AUTO_ASSIGN && (unsigned)irq >= NR_IRQ_VECTORS);
 
+	if (irq < PIRQ_BASE || irq - PIRQ_BASE > NR_PIRQS)
+		return -EINVAL;
+
 	spin_lock_irqsave(&vector_lock, flags);
 
 	if (irq != AUTO_ASSIGN && IO_APIC_VECTOR(irq) > 0) {
Index: head-2008-11-04/arch/x86_64/kernel/io_apic-xen.c
==================================================================---
head-2008-11-04.orig/arch/x86_64/kernel/io_apic-xen.c	2008-11-04
13:45:24.000000000 +0100
+++ head-2008-11-04/arch/x86_64/kernel/io_apic-xen.c	2008-11-05
12:10:12.000000000 +0100
@@ -855,6 +855,9 @@ static int __assign_irq_vector(int irq, 
   
   	BUG_ON(irq != AUTO_ASSIGN && (unsigned)irq >= NR_IRQ_VECTORS);
 
+	if (irq < PIRQ_BASE || irq - PIRQ_BASE > NR_PIRQS)
+		return -EINVAL;
+
 	spin_lock_irqsave(&vector_lock, flags);
 
   	if (irq != AUTO_ASSIGN && IO_APIC_VECTOR(irq) > 0) {
Index: head-2008-11-04/drivers/xen/core/evtchn.c
==================================================================---
head-2008-11-04.orig/drivers/xen/core/evtchn.c	2008-10-29 11:35:18.000000000
+0100
+++ head-2008-11-04/drivers/xen/core/evtchn.c	2008-11-05 13:56:23.000000000
+0100
@@ -784,71 +784,6 @@ static struct irq_chip dynirq_chip = {
 	.retrigger = resend_irq_on_evtchn,
 };
 
-void evtchn_register_pirq(int irq)
-{
-	struct irq_desc *desc;
-	unsigned long flags;
-
-	irq_info[irq] = mk_irq_info(IRQT_PIRQ, irq, 0);
-
-	/* Cannot call set_irq_probe(), as that''s marked __init. */
-	desc = irq_desc + irq;
-	spin_lock_irqsave(&desc->lock, flags);
-	desc->status &= ~IRQ_NOPROBE;
-	spin_unlock_irqrestore(&desc->lock, flags);
-}
-
-#if defined(CONFIG_X86_IO_APIC)
-#define identity_mapped_irq(irq) (!IO_APIC_IRQ((irq) - PIRQ_BASE))
-#elif defined(CONFIG_X86)
-#define identity_mapped_irq(irq) (((irq) - PIRQ_BASE) < 16)
-#else
-#define identity_mapped_irq(irq) (1)
-#endif
-
-int evtchn_map_pirq(int irq, int xen_pirq)
-{
-	if (irq < 0) {
-		static DEFINE_SPINLOCK(irq_alloc_lock);
-
-		irq = PIRQ_BASE + NR_PIRQS - 1;
-		spin_lock(&irq_alloc_lock);
-		do {
-			if (identity_mapped_irq(irq))
-				continue;
-			if (!index_from_irq(irq)) {
-				BUG_ON(type_from_irq(irq) != IRQT_UNBOUND);
-				irq_info[irq] = mk_irq_info(IRQT_PIRQ,
-							    xen_pirq, 0);
-				break;
-			}
-		} while (--irq >= PIRQ_BASE);
-		spin_unlock(&irq_alloc_lock);
-		if (irq < PIRQ_BASE)
-			return -ENOSPC;
-	} else if (!xen_pirq) {
-		if (unlikely(type_from_irq(irq) != IRQT_PIRQ))
-			return -EINVAL;
-		irq_info[irq] = IRQ_UNBOUND;
-		return 0;
-	} else if (type_from_irq(irq) != IRQT_PIRQ
-		   || index_from_irq(irq) != xen_pirq) {
-		printk(KERN_ERR "IRQ#%d is already mapped to %d:%u - "
-				"cannot map to PIRQ#%u\n",
-		       irq, type_from_irq(irq), index_from_irq(irq), xen_pirq);
-		return -EINVAL;
-	}
-	return index_from_irq(irq) ? irq : -EINVAL;
-}
-
-int evtchn_get_xen_pirq(int irq)
-{
-	if (identity_mapped_irq(irq))
-		return irq;
-	BUG_ON(type_from_irq(irq) != IRQT_PIRQ);
-	return index_from_irq(irq);
-}
-
 static inline void pirq_unmask_notify(int irq)
 {
 	struct physdev_eoi eoi = { .irq = evtchn_get_xen_pirq(irq) };
@@ -1161,6 +1096,68 @@ void irq_resume(void)
 
 }
 
+#if defined(CONFIG_X86_IO_APIC)
+#define identity_mapped_irq(irq) (!IO_APIC_IRQ((irq) - PIRQ_BASE))
+#elif defined(CONFIG_X86)
+#define identity_mapped_irq(irq) (((irq) - PIRQ_BASE) < 16)
+#else
+#define identity_mapped_irq(irq) (1)
+#endif
+
+void evtchn_register_pirq(int irq)
+{
+	BUG_ON(irq < PIRQ_BASE || irq - PIRQ_BASE > NR_PIRQS);
+	if (identity_mapped_irq(irq))
+		return;
+	irq_info[irq] = mk_irq_info(IRQT_PIRQ, irq, 0);
+	irq_desc[irq].chip = &pirq_type;
+}
+
+int evtchn_map_pirq(int irq, int xen_pirq)
+{
+	if (irq < 0) {
+		static DEFINE_SPINLOCK(irq_alloc_lock);
+
+		irq = PIRQ_BASE + NR_PIRQS - 1;
+		spin_lock(&irq_alloc_lock);
+		do {
+			if (identity_mapped_irq(irq))
+				continue;
+			if (!index_from_irq(irq)) {
+				BUG_ON(type_from_irq(irq) != IRQT_UNBOUND);
+				irq_info[irq] = mk_irq_info(IRQT_PIRQ,
+							    xen_pirq, 0);
+				break;
+			}
+		} while (--irq >= PIRQ_BASE);
+		spin_unlock(&irq_alloc_lock);
+		if (irq < PIRQ_BASE)
+			return -ENOSPC;
+		irq_desc[irq].chip = &pirq_type;
+	} else if (!xen_pirq) {
+		if (unlikely(type_from_irq(irq) != IRQT_PIRQ))
+			return -EINVAL;
+		irq_desc[irq].chip = &no_irq_type;
+		irq_info[irq] = IRQ_UNBOUND;
+		return 0;
+	} else if (type_from_irq(irq) != IRQT_PIRQ
+		   || index_from_irq(irq) != xen_pirq) {
+		printk(KERN_ERR "IRQ#%d is already mapped to %d:%u - "
+				"cannot map to PIRQ#%u\n",
+		       irq, type_from_irq(irq), index_from_irq(irq), xen_pirq);
+		return -EINVAL;
+	}
+	return index_from_irq(irq) ? irq : -EINVAL;
+}
+
+int evtchn_get_xen_pirq(int irq)
+{
+	if (identity_mapped_irq(irq))
+		return irq;
+	BUG_ON(type_from_irq(irq) != IRQT_PIRQ);
+	return index_from_irq(irq);
+}
+
 void __init xen_init_IRQ(void)
 {
 	unsigned int i;
@@ -1197,16 +1195,16 @@ void __init xen_init_IRQ(void)
 	for (i = PIRQ_BASE; i < (PIRQ_BASE + NR_PIRQS); i++) {
 		irq_bindcount[i] = 1;
 
+		if (!identity_mapped_irq(i))
+			continue;
+
 #ifdef RTC_IRQ
 		/* If not domain 0, force our RTC driver to fail its probe. */
-		if (identity_mapped_irq(i) && ((i - PIRQ_BASE) == RTC_IRQ)
-		    && !is_initial_xendomain())
+		if (i - PIRQ_BASE == RTC_IRQ && !is_initial_xendomain())
 			continue;
 #endif
 
 		irq_desc[i].status = IRQ_DISABLED;
-		if (!identity_mapped_irq(i))
-			irq_desc[i].status |= IRQ_NOPROBE;
 		irq_desc[i].action = NULL;
 		irq_desc[i].depth = 1;
 		irq_desc[i].chip = &pirq_type;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Jan Beulich

2008-Nov-05 15:30 UTC

head link

Re: [Xen-devel] [PATCH] linux: prevent invalid or unsupportablePIRQsfrom being used

>>> Keir Fraser <keir.fraser@eu.citrix.com> 05.11.08 16:26
>>>
>On 5/11/08 15:20, "Jan Beulich" <jbeulich@novell.com> wrote:
>
>> Clearly, growing NR_IRQS will be necessary here, perhaps based on
>> Linux'' x86-64 scheme of assigning IRQs and their vectors on a
per-CPU
>> basis. Are there any plans in that direction?
>
>Not for 2.6.18. Perhaps for pv_ops, if latest kernels don''t have
such
>functionality already. Remember we''re obsoleting the 2.6.18 tree
before Xen
>3.4, assuming Jeremy gets the dom0 stuff worked out by then (and
there''s no
>reason to think he won''t).
Oh, I meant NR_IRQS in Xen, not in Linux. I referred to Linux only because
it already has a solution that likely could be leveraged.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Xen devel - Nov 2008 - [PATCH] linux: prevent invalid or unsupportable PIRQs from being used

[Xen-devel] [PATCH] linux: prevent invalid or unsupportable PIRQs from being used

Re: [Xen-devel] [PATCH] linux: prevent invalid or unsupportable PIRQs from being used

Re: [Xen-devel] [PATCH] linux: prevent invalid or unsupportable PIRQsfrom being used

Re: [Xen-devel] [PATCH] linux: prevent invalid or unsupportable PIRQsfrom being used

Re: [Xen-devel] [PATCH] linux: prevent invalid or unsupportablePIRQs from being used

Re: [Xen-devel] [PATCH] linux: prevent invalid or unsupportablePIRQsfrom being used