public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Yinghai Lu <yinghai@kernel.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Ingo Molnar <mingo@elte.hu>, Thomas Renninger <trenn@suse.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Tvrtko Ursulin <tvrtko.ursulin@sophos.com>,
	Gleb Natapov <gleb@redhat.com>, 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: Re: [PATCH] x86/apic: Map the local apic when parsing the MP table.
Date: Wed, 04 Aug 2010 14:49:40 -0700	[thread overview]
Message-ID: <4C59E074.1080400@kernel.org> (raw)
In-Reply-To: <m1eiee86jg.fsf_-_@fess.ebiederm.org>

On 08/04/2010 01:30 PM, Eric W. Biederman wrote:
> 
> 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);
>  

Acked-by: Yinghai Lu <yinghai@kernel.org>

will send out another two patches on top this one for cleanup.

Yinghai

  reply	other threads:[~2010-08-04 21:51 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                       ` [PATCH] x86/apic: Map the local apic when parsing the MP table Eric W. Biederman
2010-08-04 21:49                         ` Yinghai Lu [this message]
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=4C59E074.1080400@kernel.org \
    --to=yinghai@kernel.org \
    --cc=avi@redhat.com \
    --cc=ebiederm@xmission.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 \
    /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