The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org,
	Greg KH <gregkh@linuxfoundation.org>,
	linbao.zhang@hp.com, "Eric W. Biederman" <ebiederm@xmission.com>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>
Subject: [PATCH 3/3] x86, ioapic: Move nr_ioapic_registers calculation to mp_register_ioapic.
Date: Wed, 24 Oct 2012 12:43:30 -0700	[thread overview]
Message-ID: <20121024194330.GF3120@elie.Belkin> (raw)
In-Reply-To: <20121024194114.GC3120@elie.Belkin>

From: "Eric W. Biederman" <ebiederm@xmission.com>
Date: Tue, 30 Mar 2010 01:07:12 -0700

commit 7716a5c4ff5f1f3dc5e9edcab125cbf7fceef0af upstream.

Now that all ioapic registration happens in mp_register_ioapic we can
move the calculation of nr_ioapic_registers there from enable_IO_APIC.
The number of ioapic registers is already calucated in mp_register_ioapic
so all that really needs to be done is to save the caluclated value
in nr_ioapic_registers.

[suresh.b.siddha@intel.com: backport to 2.6.32.y and 2.6.34.y:

 Lin Bao reported that one of the HP platforms failed to boot
 2.6.32 kernel, when the BIOS enabled interrupt-remapping and
 x2apic before handing over the control to the Linux kernel.

 During boot, Linux kernel masks all the interrupt sources
 (8259, IO-APIC RTE's), setup the interrupt-remapping hardware
 with the OS controlled table and unmasks the 8259 interrupts
 but not the IO-APIC RTE's (as the newly setup interrupt-remapping
 table and the IO-APIC RTE's are not yet programmed by the kernel).

 Shortly after this, IO-APIC RTE's and the interrupt-remapping table
 entries are programmed based on the ACPI tables etc. So the
 expectation is that any interrupt during this window will be dropped
 and not see the intermediate configuration.

 In the reported problematic case, BIOS has configured the IO-APIC
 in virtual wire-B mode. Between the window of the kernel setting up
 new interrupt-remapping table  and the IO-APIC RTE's are properly
 configured, an interrupt gets routed by the IO-APIC RTE (setup
 by the virtual wire-B configuration) and sees the empty
 interrupt-remapping table entry, resulting in vt-d fault causing
 the platform to generate NMI. And the OS panics on this unexpected NMI.

 This problem doesn't happen with more recent kernels and closer
 look at the 2.6.32 kernel shows that the code which masks
 the IO-APIC RTE's is not working as expected as the nr_ioapic_registers
 for each IO-APIC is not yet initialized at this point. In the later
 kernels we initialize nr_ioapic_registers much before and
 everything works as expected.]

[jrnieder@gmail.com: include removal of nr_ioapic_registers calculation
 from enable_IO_APIC() to complete the backport]

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
LKML-Reference: <1269936436-7039-11-git-send-email-ebiederm@xmission.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Reported-by: Zhang, Lin-Bao <linbao.zhang@hp.com>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
 arch/x86/kernel/apic/io_apic.c | 22 ++++++++--------------
 1 file changed, 8 insertions(+), 14 deletions(-)

diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 7a5087640599..6b7d97f1f5e5 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -1945,20 +1945,8 @@ static struct { int pin, apic; } ioapic_i8259 = { -1, -1 };
 
 void __init enable_IO_APIC(void)
 {
-	union IO_APIC_reg_01 reg_01;
 	int i8259_apic, i8259_pin;
 	int apic;
-	unsigned long flags;
-
-	/*
-	 * The number of IO-APIC IRQ registers (== #pins):
-	 */
-	for (apic = 0; apic < nr_ioapics; apic++) {
-		spin_lock_irqsave(&ioapic_lock, flags);
-		reg_01.raw = io_apic_read(apic, 1);
-		spin_unlock_irqrestore(&ioapic_lock, flags);
-		nr_ioapic_registers[apic] = reg_01.bits.entries+1;
-	}
 
 	if (!nr_legacy_irqs)
 		return;
@@ -4265,6 +4253,7 @@ static int bad_ioapic(unsigned long address)
 void __init mp_register_ioapic(int id, u32 address, u32 gsi_base)
 {
 	int idx = 0;
+	int entries;
 
 	if (bad_ioapic(address))
 		return;
@@ -4283,9 +4272,14 @@ void __init mp_register_ioapic(int id, u32 address, u32 gsi_base)
 	 * Build basic GSI lookup table to facilitate gsi->io_apic lookups
 	 * and to prevent reprogramming of IOAPIC pins (PCI GSIs).
 	 */
+	entries = io_apic_get_redir_entries(idx);
 	mp_gsi_routing[idx].gsi_base = gsi_base;
-	mp_gsi_routing[idx].gsi_end = gsi_base +
-	    io_apic_get_redir_entries(idx);
+	mp_gsi_routing[idx].gsi_end = gsi_base + entries;
+
+	/*
+	 * The number of IO-APIC IRQ registers (== #pins):
+	 */
+	nr_ioapic_registers[idx] = entries + 1;
 
 	if (mp_gsi_routing[idx].gsi_end > gsi_end)
 		gsi_end = mp_gsi_routing[idx].gsi_end;
-- 
1.8.0


  parent reply	other threads:[~2012-10-24 19:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-24 18:17 [stable 2.6.32..2.6.34] x86, ioapic: initialize nr_ioapic_registers early in mp_register_ioapic() Suresh Siddha
2012-10-24 18:25 ` Jonathan Nieder
2012-10-24 18:37   ` Suresh Siddha
2012-10-24 19:18     ` Jonathan Nieder
2012-10-24 19:41     ` [RFC/PATCH 2.6.32.y 0/3] " Jonathan Nieder
2012-10-24 19:42       ` [PATCH 1/3] x86, ioapic: Teach mp_register_ioapic to compute a global gsi_end Jonathan Nieder
2012-10-24 19:42       ` [PATCH 2/3] x86, ioapic: In mpparse use mp_register_ioapic Jonathan Nieder
2012-10-24 19:43       ` Jonathan Nieder [this message]
2012-10-24 22:24       ` [RFC/PATCH 2.6.32.y 0/3] Re: [stable 2.6.32..2.6.34] x86, ioapic: initialize nr_ioapic_registers early in mp_register_ioapic() Suresh Siddha
2012-10-24 22:31         ` Jonathan Nieder
2012-10-25  1:25           ` Eric W. Biederman
2012-11-01  7:50             ` Willy Tarreau

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=20121024194330.GF3120@elie.Belkin \
    --to=jrnieder@gmail.com \
    --cc=ebiederm@xmission.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpa@zytor.com \
    --cc=linbao.zhang@hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=suresh.b.siddha@intel.com \
    --cc=x86@kernel.org \
    /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