* [PATCH] linux: prevent invalid or unsupportable PIRQs from being used
@ 2008-11-05 14:13 Jan Beulich
2008-11-05 14:54 ` Keir Fraser
2008-11-05 15:20 ` [PATCH] linux: prevent invalid or unsupportable PIRQsfrom " Jan Beulich
0 siblings, 2 replies; 6+ messages in thread
From: Jan Beulich @ 2008-11-05 14:13 UTC (permalink / raw
To: xen-devel
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;
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] linux: prevent invalid or unsupportable PIRQs from being used
2008-11-05 14:13 [PATCH] linux: prevent invalid or unsupportable PIRQs from being used Jan Beulich
@ 2008-11-05 14:54 ` Keir Fraser
2008-11-05 15:27 ` [PATCH] linux: prevent invalid or unsupportablePIRQs " Jan Beulich
2008-11-05 15:20 ` [PATCH] linux: prevent invalid or unsupportable PIRQsfrom " Jan Beulich
1 sibling, 1 reply; 6+ messages in thread
From: Keir Fraser @ 2008-11-05 14:54 UTC (permalink / raw
To: Jan Beulich, xen-devel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] linux: prevent invalid or unsupportable PIRQsfrom being used
2008-11-05 14:13 [PATCH] linux: prevent invalid or unsupportable PIRQs from being used Jan Beulich
2008-11-05 14:54 ` Keir Fraser
@ 2008-11-05 15:20 ` Jan Beulich
2008-11-05 15:26 ` Keir Fraser
1 sibling, 1 reply; 6+ messages in thread
From: Jan Beulich @ 2008-11-05 15:20 UTC (permalink / raw
To: xen-devel
>>> "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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] linux: prevent invalid or unsupportable PIRQsfrom being used
2008-11-05 15:20 ` [PATCH] linux: prevent invalid or unsupportable PIRQsfrom " Jan Beulich
@ 2008-11-05 15:26 ` Keir Fraser
2008-11-05 15:30 ` [PATCH] linux: prevent invalid or unsupportablePIRQsfrom " Jan Beulich
0 siblings, 1 reply; 6+ messages in thread
From: Keir Fraser @ 2008-11-05 15:26 UTC (permalink / raw
To: Jan Beulich, xen-devel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] linux: prevent invalid or unsupportablePIRQs from being used
2008-11-05 14:54 ` Keir Fraser
@ 2008-11-05 15:27 ` Jan Beulich
0 siblings, 0 replies; 6+ messages in thread
From: Jan Beulich @ 2008-11-05 15:27 UTC (permalink / raw
To: Keir Fraser; +Cc: xen-devel
>>> 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;
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] linux: prevent invalid or unsupportablePIRQsfrom being used
2008-11-05 15:26 ` Keir Fraser
@ 2008-11-05 15:30 ` Jan Beulich
0 siblings, 0 replies; 6+ messages in thread
From: Jan Beulich @ 2008-11-05 15:30 UTC (permalink / raw
To: Keir Fraser; +Cc: xen-devel
>>> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2008-11-05 15:30 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-11-05 14:13 [PATCH] linux: prevent invalid or unsupportable PIRQs from being used Jan Beulich
2008-11-05 14:54 ` Keir Fraser
2008-11-05 15:27 ` [PATCH] linux: prevent invalid or unsupportablePIRQs " Jan Beulich
2008-11-05 15:20 ` [PATCH] linux: prevent invalid or unsupportable PIRQsfrom " Jan Beulich
2008-11-05 15:26 ` Keir Fraser
2008-11-05 15:30 ` [PATCH] linux: prevent invalid or unsupportablePIRQsfrom " Jan Beulich
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.