public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Ingo Molnar <mingo@elte.hu>, Thomas Renninger <trenn@suse.de>,
	"H. Peter Anvin" <hpa@zytor.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@sophos.com>,
	Gleb Natapov <gleb@redhat.com>, Yinghai Lu <yinghai@kernel.org>,
	Avi Kivity <avi@redhat.com>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	KVM list <kvm@vger.kernel.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	David Hill <hilld@binarystorm.net>
Subject: [PATCH] x86/apic: Map the local apic when parsing the MP table.
Date: Wed, 04 Aug 2010 13:30:27 -0700	[thread overview]
Message-ID: <m1eiee86jg.fsf_-_@fess.ebiederm.org> (raw)
In-Reply-To: <201008041146.56406.tvrtko.ursulin@sophos.com> (Tvrtko Ursulin's message of "Wed\, 4 Aug 2010 11\:46\:55 +0100")


This fixes a regression in 2.6.35 from 2.6.34, that is
present for select models of Intel cpus when people are
using an MP table.

The commit cf7500c0ea133d66f8449d86392d83f840102632
"x86, ioapic: In mpparse use mp_register_ioapic" started
calling mp_register_ioapic from MP_ioapic_info.  An extremely
simple change that was obviously correct.  Unfortunately
mp_register_ioapic did just a little more than the previous
hand crafted code and so we gained this call path.

The problem call path is:
MP_ioapic_info()
  mp_register_ioapic()
   io_apic_unique_id()
     io_apic_get_unique_id()
       get_physical_broadcast()
         modern_apic()
           lapic_get_version()
             apic_read(APIC_LVR)

Which turned out to be a problem because the local apic
was not mapped, at that point, unlike the similar point
in the ACPI parsing code.

This problem is fixed by mapping the local apic when
parsing the mptable as soon as we reasonably can.

Looking at the number of places we setup the fixmap for
the local apic, I see some serious simplification opportunities.
For the moment except for not duplicating the setting up of the
fixmap in init_apic_mappings, I have not acted on them.

The regression from 2.6.34 is tracked in bug
https://bugzilla.kernel.org/show_bug.cgi?id=16173

Cc: stable@kernel.org
Reported-by: David Hill <hilld@binarystorm.net>
Reported-by: Tvrtko Ursulin <tvrtko.ursulin@sophos.com>
Tested-by: Tvrtko Ursulin <tvrtko.ursulin@sophos.com>
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
 arch/x86/kernel/apic/apic.c |    2 +-
 arch/x86/kernel/mpparse.c   |   16 ++++++++++++++++
 2 files changed, 17 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index a96489e..c07e513 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1606,7 +1606,7 @@ void __init init_apic_mappings(void)
 		 * acpi lapic path already maps that address in
 		 * acpi_register_lapic_address()
 		 */
-		if (!acpi_lapic)
+		if (!acpi_lapic && !smp_found_config)
 			set_fixmap_nocache(FIX_APIC_BASE, apic_phys);
 
 		apic_printk(APIC_VERBOSE, "mapped APIC to %08lx (%08lx)\n",
diff --git a/arch/x86/kernel/mpparse.c b/arch/x86/kernel/mpparse.c
index d86dbf7..d7b6f7f 100644
--- a/arch/x86/kernel/mpparse.c
+++ b/arch/x86/kernel/mpparse.c
@@ -274,6 +274,18 @@ static void __init smp_dump_mptable(struct mpc_table *mpc, unsigned char *mpt)
 
 void __init default_smp_read_mpc_oem(struct mpc_table *mpc) { }
 
+static void __init smp_register_lapic_address(unsigned long address)
+{
+	mp_lapic_addr = address;
+
+	set_fixmap_nocache(FIX_APIC_BASE, address);
+	if (boot_cpu_physical_apicid == -1U) {
+		boot_cpu_physical_apicid  = read_apic_id();
+		apic_version[boot_cpu_physical_apicid] =
+			 GET_APIC_VERSION(apic_read(APIC_LVR));
+	}
+}
+
 static int __init smp_read_mpc(struct mpc_table *mpc, unsigned early)
 {
 	char str[16];
@@ -295,6 +307,10 @@ static int __init smp_read_mpc(struct mpc_table *mpc, unsigned early)
 	if (early)
 		return 1;
 
+	/* Initialize the lapic mapping */
+	if (!acpi_lapic)
+		smp_register_lapic_address(mpc->lapic);
+
 	if (mpc->oemptr)
 		x86_init.mpparse.smp_read_mpc_oem(mpc);
 
-- 
1.6.5.2.143.g8cc62


  reply	other threads:[~2010-08-04 20:30 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-03  9:28 2.6.35 hangs on early boot in KVM Tvrtko Ursulin
2010-08-03  9:45 ` Tvrtko Ursulin
2010-08-03 13:53   ` Tvrtko Ursulin
2010-08-03 14:51 ` Avi Kivity
2010-08-03 14:57   ` Tvrtko Ursulin
2010-08-03 15:17     ` Tvrtko Ursulin
2010-08-03 15:31       ` Tvrtko Ursulin
2010-08-03 15:49         ` Borislav Petkov
2010-08-03 16:01           ` Tvrtko Ursulin
2010-08-03 15:59       ` Tvrtko Ursulin
2010-08-03 20:37         ` Eric W. Biederman
2010-08-04  8:09           ` Tvrtko Ursulin
2010-08-03 20:57         ` Yinghai Lu
2010-08-04  8:18           ` Tvrtko Ursulin
2010-08-04  9:05             ` Yinghai Lu
2010-08-04  9:16               ` Tvrtko Ursulin
2010-08-04  9:19                 ` Tvrtko Ursulin
2010-08-04  9:34                 ` Yinghai Lu
2010-08-04  9:44                   ` Tvrtko Ursulin
2010-08-04  9:36                 ` Gleb Natapov
2010-08-04 10:37                   ` Eric W. Biederman
2010-08-04 10:46                     ` Tvrtko Ursulin
2010-08-04 20:30                       ` Eric W. Biederman [this message]
2010-08-04 21:49                         ` [PATCH] x86/apic: Map the local apic when parsing the MP table Yinghai Lu
2010-08-04 21:58                         ` [PATCH 1/2] x86, acpi: merge two register_lapic_address() Yinghai Lu
2010-08-04 22:00                           ` [PATCH 2/2] x86: remove early_init_lapic_mapping Yinghai Lu
2010-08-06  0:15                         ` [tip:x86/urgent] x86, apic: Map the local apic when parsing the MP table tip-bot for Eric W. Biederman
2010-08-07  0:08                           ` Yinghai Lu
2010-08-07  0:15                             ` H. Peter Anvin
2010-08-07  0:51                               ` Yinghai Lu
2010-08-07  1:08                               ` Eric W. Biederman
2010-08-07  1:21                                 ` H. Peter Anvin
2010-08-07  1:30                                   ` Yinghai Lu
2010-08-07  2:49                                     ` 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=m1eiee86jg.fsf_-_@fess.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=avi@redhat.com \
    --cc=gleb@redhat.com \
    --cc=hilld@binarystorm.net \
    --cc=hpa@zytor.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rjw@sisk.pl \
    --cc=trenn@suse.de \
    --cc=tvrtko.ursulin@sophos.com \
    --cc=yinghai@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