All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Cc: fengguang.wu@intel.com, kexec@lists.infradead.org,
	linux-kernel@vger.kernel.org, bp@alien8.de,
	ebiederm@xmission.com, akpm@linux-foundation.org,
	hpa@linux.intel.com, jingbai.ma@hp.com
Subject: Re: [PATCH v4 1/3] x86, apic: Don't count the CPU with BP flag from MP table as booting-up CPU
Date: Mon, 11 Nov 2013 11:52:03 -0500	[thread overview]
Message-ID: <20131111165202.GD11547@redhat.com> (raw)
In-Reply-To: <5280466E.9090504@jp.fujitsu.com>

On Mon, Nov 11, 2013 at 11:52:30AM +0900, HATAYAMA Daisuke wrote:

[..]
> Looking at my past investigation, kernel/mpparse.c, mm/amdtopology.c and
> platform/visws/visws_quirks.c assumes that boot_cpu_physical_apicid
> has initial apicid of the BSP, not the current actual booting-up cpu.
> 
> These three are called in get_smp_config() below. If either of them is
> called actually, boot_cpu_physical_apicid has the apicid different from
> the current actual booting-up cpu temporarily. But init_apic_mappings()
> soon modifies back the value to the one obtained by read_apic_id().
> 
>         /*
>          * Read APIC and some other early information from ACPI tables.
>          */
>         acpi_boot_init();
>         sfi_init();
>         x86_dtb_init();
> 
>         /*
>          * get boot-time SMP configuration:
>          */
>         if (smp_found_config)
>                 get_smp_config();
> 
>         prefill_possible_map();
> 
>         init_cpu_to_node();
> 
>         init_apic_mappings();
> 
> So, thanks to init_apic_mappings(), the patch set would work without the
> first patch... This is a careless point in this patch set.
> 

If init_apic_mappings(), is making sure that boot_cpu_physical_apicid is
apic id of booting processor, and you don't need first patch of your
series, then I think atleast re-post your patch series without first
patch.  

And then there can be another series which looks into whether we need
two different variables or not and if we do, then a separate variable
bsp_physical_apicid will track the bsp id as reported by BIOS and
boot_cpu_physical_apicid will track apic id of booting cpu. This might
a very big and slow cleanup. So I think blocking the first patch series
behind it might not make much sense.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: Vivek Goyal <vgoyal@redhat.com>
To: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Cc: hpa@linux.intel.com, ebiederm@xmission.com,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	bp@alien8.de, akpm@linux-foundation.org, fengguang.wu@intel.com,
	jingbai.ma@hp.com
Subject: Re: [PATCH v4 1/3] x86, apic: Don't count the CPU with BP flag from MP table as booting-up CPU
Date: Mon, 11 Nov 2013 11:52:03 -0500	[thread overview]
Message-ID: <20131111165202.GD11547@redhat.com> (raw)
In-Reply-To: <5280466E.9090504@jp.fujitsu.com>

On Mon, Nov 11, 2013 at 11:52:30AM +0900, HATAYAMA Daisuke wrote:

[..]
> Looking at my past investigation, kernel/mpparse.c, mm/amdtopology.c and
> platform/visws/visws_quirks.c assumes that boot_cpu_physical_apicid
> has initial apicid of the BSP, not the current actual booting-up cpu.
> 
> These three are called in get_smp_config() below. If either of them is
> called actually, boot_cpu_physical_apicid has the apicid different from
> the current actual booting-up cpu temporarily. But init_apic_mappings()
> soon modifies back the value to the one obtained by read_apic_id().
> 
>         /*
>          * Read APIC and some other early information from ACPI tables.
>          */
>         acpi_boot_init();
>         sfi_init();
>         x86_dtb_init();
> 
>         /*
>          * get boot-time SMP configuration:
>          */
>         if (smp_found_config)
>                 get_smp_config();
> 
>         prefill_possible_map();
> 
>         init_cpu_to_node();
> 
>         init_apic_mappings();
> 
> So, thanks to init_apic_mappings(), the patch set would work without the
> first patch... This is a careless point in this patch set.
> 

If init_apic_mappings(), is making sure that boot_cpu_physical_apicid is
apic id of booting processor, and you don't need first patch of your
series, then I think atleast re-post your patch series without first
patch.  

And then there can be another series which looks into whether we need
two different variables or not and if we do, then a separate variable
bsp_physical_apicid will track the bsp id as reported by BIOS and
boot_cpu_physical_apicid will track apic id of booting cpu. This might
a very big and slow cleanup. So I think blocking the first patch series
behind it might not make much sense.

Thanks
Vivek

  reply	other threads:[~2013-11-11 16:52 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-22 15:01 [PATCH v4 0/3] x86, apic, kexec: Add disable_cpu_apic kernel parameter HATAYAMA Daisuke
2013-10-22 15:01 ` HATAYAMA Daisuke
2013-10-22 15:01 ` [PATCH v4 1/3] x86, apic: Don't count the CPU with BP flag from MP table as booting-up CPU HATAYAMA Daisuke
2013-10-22 15:01   ` HATAYAMA Daisuke
2013-11-08 16:08   ` Vivek Goyal
2013-11-08 16:08     ` Vivek Goyal
2013-11-11  2:52     ` HATAYAMA Daisuke
2013-11-11  2:52       ` HATAYAMA Daisuke
2013-11-11 16:52       ` Vivek Goyal [this message]
2013-11-11 16:52         ` Vivek Goyal
2013-11-12  0:40         ` HATAYAMA Daisuke
2013-11-12  0:40           ` HATAYAMA Daisuke
2013-11-12  9:58           ` HATAYAMA Daisuke
2013-11-12  9:58             ` HATAYAMA Daisuke
2013-10-22 15:01 ` [PATCH v4 2/3] x86, apic: Add disable_cpu_apicid kernel parameter HATAYAMA Daisuke
2013-10-22 15:01   ` HATAYAMA Daisuke
2013-10-22 15:01 ` [PATCH v4 3/3] Documentation, x86, apic, kexec: " HATAYAMA Daisuke
2013-10-22 15:01   ` HATAYAMA Daisuke
2013-10-22 22:08 ` [PATCH v4 0/3] x86, apic, kexec: Add disable_cpu_apic " jerry.hoemann
2013-10-23  0:05   ` HATAYAMA Daisuke
2013-10-23  0:05     ` HATAYAMA Daisuke
2013-10-23 15:51     ` Vivek Goyal
2013-10-23 15:51       ` Vivek Goyal
2013-10-24  1:42       ` HATAYAMA Daisuke
2013-10-24  1:42         ` HATAYAMA Daisuke
2013-10-25 11:05         ` Petr Tesarik
2013-10-29  0:53           ` HATAYAMA Daisuke
2013-10-29  7:39             ` Petr Tesarik
2013-10-24  5:50       ` Eric W. Biederman
2013-10-24  5:50         ` Eric W. Biederman
2013-10-31  0:58     ` jerry.hoemann
2013-10-31  4:43       ` HATAYAMA Daisuke
2013-10-31  4:43         ` HATAYAMA Daisuke
2013-10-31 13:27       ` Vivek Goyal
2013-10-31 13:27         ` Vivek Goyal
2013-11-01  0:31         ` Simon Horman
2013-11-01  0:31           ` Simon Horman
2013-11-01  7:54         ` jerry.hoemann
2013-11-04  7:08         ` HATAYAMA Daisuke
2013-11-04  7:08           ` HATAYAMA Daisuke
2013-10-29 14:21 ` Baoquan He
2013-10-29 14:21   ` Baoquan He
2013-10-30  0:44   ` HATAYAMA Daisuke
2013-10-30  0:44     ` HATAYAMA Daisuke
2013-10-30  6:06     ` Baoquan He
2013-10-30  6:06       ` Baoquan He
2013-10-30  9:48       ` HATAYAMA Daisuke
2013-10-30  9:48         ` HATAYAMA Daisuke
2013-10-30 15:27   ` Baoquan He
2013-10-30 15:27     ` Baoquan He
2013-11-06 19:02 ` jerry.hoemann
2013-11-11  4:49   ` HATAYAMA Daisuke
2013-11-11  4:49     ` HATAYAMA Daisuke
2013-11-13 18:27     ` jerry.hoemann
2013-11-08  3:30 ` Baoquan He
2013-11-08  3:30   ` Baoquan He
2013-11-08  4:13   ` HATAYAMA Daisuke
2013-11-08  4:13     ` HATAYAMA Daisuke

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=20131111165202.GD11547@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=d.hatayama@jp.fujitsu.com \
    --cc=ebiederm@xmission.com \
    --cc=fengguang.wu@intel.com \
    --cc=hpa@linux.intel.com \
    --cc=jingbai.ma@hp.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.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 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.