All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@novell.com>
To: "Yinghai Lu" <yhlu.kernel@gmail.com>
Cc: "Jeremy Fitzhardinge" <jeremy@goop.org>,
	"Len Brown" <lenb@kernel.org>,
	"the arch/x86 maintainers" <x86@kernel.org>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Xen-devel" <xen-devel@lists.xensource.com>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: [Xen-devel] Re: [PATCH RFC] x86/acpi: don't ignore I/O APICs justbecause there's no local APIC
Date: Fri, 19 Jun 2009 08:52:13 +0100	[thread overview]
Message-ID: <4A3B5FCD0200007800006AC0@vpn.id2.novell.com> (raw)
In-Reply-To: <86802c440906182232r31088e4fh3613a8da6f8903f7@mail.gmail.com>

>>> Yinghai Lu <yhlu.kernel@gmail.com> 19.06.09 07:32 >>>
>doesn't XEN support per cpu irq vector?

No.

>got sth from XEN 3.3 / SLES 11
>
>igb 0000:81:00.0: PCI INT A -> GSI 95 (level, low) -> IRQ 95
>igb 0000:81:00.0: setting latency timer to 64
>igb 0000:81:00.0: Intel(R) Gigabit Ethernet Network Connection
>igb 0000:81:00.0: eth9: (PCIe:2.5Gb/s:Width x4) 00:21:28:3a:d8:0e
>igb 0000:81:00.0: eth9: PBA No: ffffff-0ff
>igb 0000:81:00.0: Using MSI-X interrupts. 4 rx queue(s), 4 tx queue(s)
>vendor=8086 device=3420
>(XEN) irq.c:847: dom0: invalid pirq 94 or vector -28
>igb 0000:81:00.1: PCI INT B -> GSI 94 (level, low) -> IRQ 94
>igb 0000:81:00.1: setting latency timer to 64
>(XEN) physdev.c:87: dom0: map irq with wrong vector -28
>map irq failed
>(XEN) physdev.c:87: dom0: map irq with wrong vector -28
>map irq failed
>
>the system need a lot of MSI-X normally.. with current mainline tree
>kernel, it will need about 360 irq...

Do you mean 360 connected devices, or just 360 IO-APIC pins (most of
which are usually unused)? In the latter case, devices using MSI (i.e. not
using high numbered IO-APIC pins) should work, while devices connected
to IO-APIC pins numbered 256 and higher won't work in SLE11 as-is.
This limitation got fixed recently in the 3.5-unstable tree, though. The
256 active vectors limit, however, continues to exist, so the former case
would still not be supported by Xen.

Jan


WARNING: multiple messages have this Message-ID (diff)
From: "Jan Beulich" <JBeulich@novell.com>
To: Yinghai Lu <yhlu.kernel@gmail.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Xen-devel <xen-devel@lists.xensource.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>, Len Brown <lenb@kernel.org>
Subject: Re: [PATCH RFC] x86/acpi: don't ignore I/O APICs justbecause there's no local APIC
Date: Fri, 19 Jun 2009 08:52:13 +0100	[thread overview]
Message-ID: <4A3B5FCD0200007800006AC0@vpn.id2.novell.com> (raw)
In-Reply-To: <86802c440906182232r31088e4fh3613a8da6f8903f7@mail.gmail.com>

>>> Yinghai Lu <yhlu.kernel@gmail.com> 19.06.09 07:32 >>>
>doesn't XEN support per cpu irq vector?

No.

>got sth from XEN 3.3 / SLES 11
>
>igb 0000:81:00.0: PCI INT A -> GSI 95 (level, low) -> IRQ 95
>igb 0000:81:00.0: setting latency timer to 64
>igb 0000:81:00.0: Intel(R) Gigabit Ethernet Network Connection
>igb 0000:81:00.0: eth9: (PCIe:2.5Gb/s:Width x4) 00:21:28:3a:d8:0e
>igb 0000:81:00.0: eth9: PBA No: ffffff-0ff
>igb 0000:81:00.0: Using MSI-X interrupts. 4 rx queue(s), 4 tx queue(s)
>vendor=8086 device=3420
>(XEN) irq.c:847: dom0: invalid pirq 94 or vector -28
>igb 0000:81:00.1: PCI INT B -> GSI 94 (level, low) -> IRQ 94
>igb 0000:81:00.1: setting latency timer to 64
>(XEN) physdev.c:87: dom0: map irq with wrong vector -28
>map irq failed
>(XEN) physdev.c:87: dom0: map irq with wrong vector -28
>map irq failed
>
>the system need a lot of MSI-X normally.. with current mainline tree
>kernel, it will need about 360 irq...

Do you mean 360 connected devices, or just 360 IO-APIC pins (most of
which are usually unused)? In the latter case, devices using MSI (i.e. not
using high numbered IO-APIC pins) should work, while devices connected
to IO-APIC pins numbered 256 and higher won't work in SLE11 as-is.
This limitation got fixed recently in the 3.5-unstable tree, though. The
256 active vectors limit, however, continues to exist, so the former case
would still not be supported by Xen.

Jan

  parent reply	other threads:[~2009-06-19  7:52 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-12 18:22 [PATCH RFC] x86/acpi: don't ignore I/O APICs just because there's no local APIC Jeremy Fitzhardinge
2009-06-12 18:22 ` Jeremy Fitzhardinge
2009-06-12 18:28 ` Alan Cox
2009-06-12 18:28   ` Alan Cox
2009-06-12 18:33   ` Jeremy Fitzhardinge
2009-06-12 18:33     ` Jeremy Fitzhardinge
2009-06-12 20:11 ` Cyrill Gorcunov
2009-06-15  2:01   ` Jeremy Fitzhardinge
2009-06-12 20:35 ` Eric W. Biederman
2009-06-12 20:35   ` Eric W. Biederman
2009-06-15  2:06   ` Jeremy Fitzhardinge
2009-06-15 10:47     ` Eric W. Biederman
2009-06-15 10:47       ` Eric W. Biederman
2009-06-15 20:49       ` Jeremy Fitzhardinge
2009-06-15 20:49         ` Jeremy Fitzhardinge
2009-06-15 21:58         ` Eric W. Biederman
2009-06-15 21:58           ` Eric W. Biederman
2009-06-16 19:38           ` Jeremy Fitzhardinge
2009-06-16 19:38             ` Jeremy Fitzhardinge
2009-06-17  5:10             ` Eric W. Biederman
2009-06-17  5:10               ` Eric W. Biederman
2009-06-17 12:02             ` Eric W. Biederman
2009-06-17 12:02               ` Eric W. Biederman
2009-06-17 17:32               ` Jeremy Fitzhardinge
2009-06-17 17:32                 ` Jeremy Fitzhardinge
2009-06-18  2:58                 ` Eric W. Biederman
2009-06-18  2:58                   ` Eric W. Biederman
2009-06-18 19:34                   ` Jeremy Fitzhardinge
2009-06-18 19:34                     ` Jeremy Fitzhardinge
2009-06-18 20:28                     ` Eric W. Biederman
2009-06-18 21:09                       ` Jeremy Fitzhardinge
2009-06-18 21:09                         ` Jeremy Fitzhardinge
2009-06-19  1:38                         ` Eric W. Biederman
2009-06-19  1:38                           ` Eric W. Biederman
2009-06-19  3:10                           ` [Xen-devel] " Jiang, Yunhong
2009-06-19  3:10                             ` Jiang, Yunhong
2009-06-18 12:26                 ` Eric W. Biederman
2009-06-15 10:51 ` Eric W. Biederman
2009-06-15 10:51   ` Eric W. Biederman
2009-06-18 16:08 ` Len Brown
2009-06-18 19:14   ` Jeremy Fitzhardinge
2009-06-18 19:14     ` Jeremy Fitzhardinge
2009-06-18 19:27     ` Eric W. Biederman
2009-06-18 19:48       ` Jeremy Fitzhardinge
2009-06-18 19:48         ` Jeremy Fitzhardinge
2009-06-18 20:39         ` Eric W. Biederman
2009-06-18 22:33           ` Jeremy Fitzhardinge
2009-06-18 22:33             ` Jeremy Fitzhardinge
2009-06-19  2:42             ` Eric W. Biederman
2009-06-19  2:42               ` Eric W. Biederman
2009-06-19 19:58               ` Jeremy Fitzhardinge
2009-06-19 19:58                 ` Jeremy Fitzhardinge
2009-06-19 23:44                 ` [Xen-devel] " Nakajima, Jun
2009-06-19 23:44                   ` Nakajima, Jun
2009-06-20  7:39                   ` [Xen-devel] " Keir Fraser
2009-06-20  7:39                     ` Keir Fraser
2009-06-20  8:21                     ` [Xen-devel] " Eric W. Biederman
2009-06-20  8:21                       ` Eric W. Biederman
2009-06-20  8:57                       ` [Xen-devel] " Tian, Kevin
2009-06-20  8:57                         ` Tian, Kevin
2009-06-20 10:22                         ` [Xen-devel] " Keir Fraser
2009-06-20 10:22                           ` Keir Fraser
2009-06-20  8:18                   ` [Xen-devel] " Eric W. Biederman
2009-06-20  8:18                     ` Eric W. Biederman
2009-06-19  5:32             ` Yinghai Lu
2009-06-19  5:32               ` Yinghai Lu
2009-06-19  5:50               ` Eric W. Biederman
2009-06-19  5:50                 ` Eric W. Biederman
2009-06-19  7:52               ` Jan Beulich [this message]
2009-06-19  7:52                 ` [PATCH RFC] x86/acpi: don't ignore I/O APICs justbecause " Jan Beulich
2009-06-19  8:16                 ` [Xen-devel] " Eric W. Biederman
2009-06-19  8:16                   ` Eric W. Biederman
2009-06-20  3:58                   ` [Xen-devel] " Yinghai Lu
2009-06-20  3:58                     ` Yinghai Lu
2009-06-20  5:40                     ` [Xen-devel] " Eric W. Biederman
2009-06-20  5:40                       ` Eric W. Biederman
2009-06-20  5:58                       ` [Xen-devel] " Yinghai Lu
2009-06-20  5:58                         ` Yinghai Lu
2009-06-18 22:51     ` [PATCH RFC] x86/acpi: don't ignore I/O APICs just because " Maciej W. Rozycki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A3B5FCD0200007800006AC0@vpn.id2.novell.com \
    --to=jbeulich@novell.com \
    --cc=ebiederm@xmission.com \
    --cc=hpa@zytor.com \
    --cc=jeremy@goop.org \
    --cc=lenb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=xen-devel@lists.xensource.com \
    --cc=yhlu.kernel@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.