From: ebiederm@xmission.com (Eric W. Biederman)
To: Vivek Goyal <vgoyal@redhat.com>
Cc: fengguang.wu@intel.com, kexec@lists.infradead.org,
jerry.hoemann@hp.com, linux-kernel@vger.kernel.org,
HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>,
bp@alien8.de, akpm@linux-foundation.org, hpa@linux.intel.com,
jingbai.ma@hp.com
Subject: Re: [PATCH v4 0/3] x86, apic, kexec: Add disable_cpu_apic kernel parameter
Date: Wed, 23 Oct 2013 22:50:13 -0700 [thread overview]
Message-ID: <871u3bcj56.fsf@xmission.com> (raw)
In-Reply-To: <20131023155127.GA17437@redhat.com> (Vivek Goyal's message of "Wed, 23 Oct 2013 11:51:27 -0400")
Vivek Goyal <vgoyal@redhat.com> writes:
> Hi Hatayama,
>
> So what information should I look for to prepare disable_cpu_apic=X in
> kdump script?
>
> Is BSP processor info exported to user space somewhere? Or assuming that
> processor 0 is BSP and corresponding apicid should be disabled in kdump
> kernel is good enough?
On x86 assuming that processor 0 is BSP should be good enough. Unless
we starting getting SMP BIOSen playing games with us.
> I am looking at /proc/cpuinfo and following 3 fields seem interesting.
>
> processor: 0
> apicid : 0
> initial apicid : 0
>
> What's the difference between apicid and "initial apicid". I guess
> initial apicid reflects the apicid number as set by firmware and then
> kernel can overwrite it and new number would be reflected in "apicid"?
Last I was current initial apicid is the apic id the hardware chooses
and it tells you something about the topology of the processors in the
system.
The apicid is programmed by the BIOS so that the BSP can have apicid 0,
and apicid's can be contiguous etc. In principle any piece of software
can program apicids but there is no advantage.
> If that's the case, then I guess we should be looking at "apicid" of
> processor "0" and set that in disable_cpu_apic? Because that's the
> number kdump kernel boot should see in apic upon boot.
Restricting this to x86 and not Voyager that is correct. Linux cpu 0
is the processor we booted up on as is apparent lots of things special
case the bootstrap processor so using a cpu hotplug remove to make it go
away is silly. Still to handle cazy cpu hotplug I would recomend to
simply force a single cpu if you can't find cpu 0.
Eric
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2013-10-24 5:51 UTC|newest]
Thread overview: 28+ 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 ` [PATCH v4 1/3] x86, apic: Don't count the CPU with BP flag from MP table as booting-up CPU HATAYAMA Daisuke
2013-11-08 16:08 ` Vivek Goyal
2013-11-11 2:52 ` HATAYAMA Daisuke
2013-11-11 16:52 ` Vivek Goyal
2013-11-12 0:40 ` 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 ` [PATCH v4 3/3] Documentation, x86, apic, kexec: " HATAYAMA Daisuke
[not found] ` <20131022220803.GA32387@anatevka.fc.hp.com>
2013-10-23 0:05 ` [PATCH v4 0/3] x86, apic, kexec: Add disable_cpu_apic " HATAYAMA Daisuke
2013-10-23 15:51 ` Vivek Goyal
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 [this message]
[not found] ` <20131031005812.GA15459@anatevka.fc.hp.com>
2013-10-31 4:43 ` HATAYAMA Daisuke
2013-10-31 13:27 ` Vivek Goyal
2013-11-01 0:31 ` Simon Horman
2013-11-04 7:08 ` HATAYAMA Daisuke
2013-10-29 14:21 ` Baoquan He
2013-10-30 0:44 ` HATAYAMA Daisuke
2013-10-30 6:06 ` Baoquan He
2013-10-30 9:48 ` HATAYAMA Daisuke
2013-10-30 15:27 ` Baoquan He
2013-11-08 3:30 ` Baoquan He
2013-11-08 4:13 ` HATAYAMA Daisuke
[not found] ` <20131106190232.GA28119@anatevka.fc.hp.com>
2013-11-11 4:49 ` 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=871u3bcj56.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=d.hatayama@jp.fujitsu.com \
--cc=fengguang.wu@intel.com \
--cc=hpa@linux.intel.com \
--cc=jerry.hoemann@hp.com \
--cc=jingbai.ma@hp.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vgoyal@redhat.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