All of lore.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 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.