From: Grant Grundler <grundler@parisc-linux.org>
To: "Randy.Dunlap" <rdunlap@xenotime.net>
Cc: lkml <linux-kernel@vger.kernel.org>, akpm <akpm@osdl.org>,
gregkh <greg@kroah.com>,
linux-pci@atrey.karlin.mff.cuni.cz, ak@suse.de
Subject: Re: [PATCH] MSI interrupts: disallow when no LAPIC/IOAPIC support
Date: Mon, 26 Sep 2005 22:48:40 -0600 [thread overview]
Message-ID: <20050927044840.GA21108@colo.lackof.org> (raw)
In-Reply-To: <20050926201156.7b9ef031.rdunlap@xenotime.net>
On Mon, Sep 26, 2005 at 08:11:56PM -0700, Randy.Dunlap wrote:
> From: Randy Dunlap <rdunlap@xenotime.net>
>
> MSI requires local APIC + IO APIC support (according to
> drivers/pci/Kconfig),
The purpose of MSI is to bypass the IO APIC.
I'm not aware of any dependency on IO APIC in HW.
I suspect the dependency in the Kconfig is historical
because of how the x86 source code is structured:
config X86_LOCAL_APIC
bool
depends on X86_UP_APIC || ((X86_VISWS || SMP) && !X86_VOYAGER)
default y
essentially, LOCAL_APIC gets enabled if "UP_APIC or SMP".
I've no clue why folks thought it was better to ignore
the IO APIC on UP kernels.
I'm pretty sure one only needs a local APIC support.
Local APIC responds to 0xfee00000 range of addresses and
directs the interrupt to a CPU.
> but if a kernel is built with all of
> those (APICs + CONFIG_PCI_MSI) and then booted with "nosmp" or
> "max_cpus=0|1" or "noapic" or "nolapic", MSI also should be
> disabled, otherwise the interrupt routing is bad (so that only
> using "irqpoll" helps).
UP vs SMP is orthogonal to MSI support wrt HW.
I suppose this is another historical artifact of
APICs being used with SMP x86 boxes first.
thanks,
grant
next prev parent reply other threads:[~2005-09-27 4:42 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-27 3:11 [PATCH] MSI interrupts: disallow when no LAPIC/IOAPIC support Randy.Dunlap
2005-09-27 4:48 ` Grant Grundler [this message]
2005-09-27 4:52 ` Randy.Dunlap
2005-09-27 5:21 ` Grant Grundler
2005-09-27 9:14 ` Mikael Pettersson
2005-09-27 15:51 ` Grant Grundler
2005-09-27 9:11 ` Mikael Pettersson
2005-09-27 21:26 ` Jeff Garzik
2005-09-27 22:37 ` Alan Cox
2005-09-29 3:34 ` Grant Grundler
2005-09-29 20:09 ` Eric W. Biederman
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=20050927044840.GA21108@colo.lackof.org \
--to=grundler@parisc-linux.org \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
--cc=rdunlap@xenotime.net \
/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.