mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: john stultz <johnstul@us.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Clark Williams <williams@redhat.com>,
	Nivedita Singhvi <niv@us.ibm.com>,
	lkml <linux-kernel@vger.kernel.org>,
	vosburgh@us.ibm.com
Subject: Re: Lapic vector priorites
Date: Mon, 23 Jan 2012 06:24:09 +0000 (GMT)	[thread overview]
Message-ID: <alpine.LFD.2.00.1201230609560.22644@eddie.linux-mips.org> (raw)
In-Reply-To: <1327297111.4129.27.camel@work-vm>

On Sun, 22 Jan 2012, john stultz wrote:

> I'm really not that familiar with the lapic code, but reading over some
> of the documentation I could find through searches, and then looking at
> the lapic vector layout in the kernel, I'm now a little curious.
> 
> >From what I've read the irq priority is set by the vector, where 0x0 is
> the highest and 0xFF is the lowest.
> 
> In irq_vectors.h I see:
> #define NMI_VECTOR			0x02
> #define MCE_VECTOR			0x12

 Both these vectors are hardwired internally in the CPU and irrelevant to 
the APIC interrupt priority levels as these apply to ordinary interrupts 
only.  For these the higher the vector value, the higher the priority (I 
won't get into the gory details, my memory has already faded about that 
and I'd have to resort to documentation to avoid confusion).

 The MCE is actually a processor exception and as such does not go through 
the APIC at all.  It's either signalled internally by the CPU (to record 
an internal malfunction) or via an external signal (to raise a bus error 
or a similar event).

 The NMI is the non-maskable interrupt and is driven by the local APIC on 
a separate processor's internal line (back in the 1990s where discrete 
local APICs were used this would actually be a separate board signal to 
the CPU) and it's the CPU that gives this line the priority above an 
ordinary interrupt that may be asserted at the same time.  For an NMI the 
CPU does not drive an INTA cycle (again, internally for modern processors) 
on its bus which the local APIC would respond with an interrupt vector to.

 I hope this helps.

  Maciej

      reply	other threads:[~2012-01-23  6:24 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-23  5:38 john stultz
2012-01-23  6:24 ` Maciej W. Rozycki [this message]

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=alpine.LFD.2.00.1201230609560.22644@eddie.linux-mips.org \
    --to=macro@linux-mips.org \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=niv@us.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=vosburgh@us.ibm.com \
    --cc=williams@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®