From: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
To: linux-kernel@vger.kernel.org, kexec@lists.infradead.org, x86@kernel.org
Cc: mingo@elte.hu, tglx@linutronix.de, hpa@zytor.com,
len.brown@intel.com, fenghua.yu@intel.com, vgoyal@redhat.com,
ebiederm@xmission.com, grant.likely@secretlab.ca,
rob.herring@calxeda.com, d.hatayama@jp.fujitsu.com
Subject: [PATCH v1 0/2] x86, apic: Disable BSP if boot cpu is AP
Date: Tue, 16 Oct 2012 13:35:17 +0900 [thread overview]
Message-ID: <20121016043357.20003.5885.stgit@localhost6.localdomain6> (raw)
Multiple CPUs are useful for CPU-bound processing like compression and
I do want to use compression to generate crash dump quickly. But now
we cannot wakeup the 2nd and later cpus in the kdump 2nd kernel if
crash happens on AP. If crash happens on AP, kexec enters the 2nd
kernel with the AP, and there BSP in the 1st kernel is expected to be
haling in the 1st kernel or possibly in any fatal system error state.
To wake up AP, we use the method called INIT-INIT-SIPI. INIT causes
BSP to jump into BIOS init code. A typical visible behaviour is hang
or immediate reset, depending on the BIOS init code.
AP can be initiated by INIT even in a fatal state: MP spec explains
that processor-specific INIT can be used to recover AP from a fatal
system error. On the other hand, there's no method for BSP to recover;
it might be possible to do so by NMI plus any hand-coded reset code
that is carefully designed, but at least I have no idea in this
direction now.
Therefore, the idea I do in this patch set is simply to disable BSP if
vboot cpu is AP.
My motivation is to use multiple CPUs in order to quickly generate
crash dump on the machine with huge amount of memory. I assume such
machine tends to also have a lot of CPUs. So disabling one CPU would
be no problem.
On most BIOSs, BSP is always assigned to cpu#1; on other BIOSs, BSP
could probably be assigned to a fixed cpu number. Assuming this fact,
it might be possible to choose an idea that waking up the cpus except
for cpu#1, not waking up cpu#1 only. But I don't choose this in this
patch set because:
- It's ugly desgin to keep switch in sysfs that can unintentionally
cause system to enter undefined behaviour.
- Memory space for BSP is never used if BSP is not running. Amount of
reserved memory for 2nd kernel is typically from 128MB to 512MB
only, severely limited. If BSP is unused, I want to use the space
for another AP instead.
Note: recent upstream kernel fails reserving memory for kdump 2nd
kernel. To run kdump, please apply the patch below on top of this
patch set:
https://lkml.org/lkml/2012/8/31/238
---
HATAYAMA Daisuke (2):
x86, apic: Disable BSP if boot cpu is AP
x86, apic: Introduce boot_cpu_is_bsp indicating whether boot cpu is BSP or not
arch/x86/include/asm/mpspec.h | 5 ++++-
arch/x86/kernel/acpi/boot.c | 10 +++++++++-
arch/x86/kernel/apic/apic.c | 34 +++++++++++++++++++++++++++++++++-
arch/x86/kernel/devicetree.c | 2 +-
arch/x86/kernel/mpparse.c | 15 +++++++++++++--
arch/x86/kernel/setup.c | 2 ++
arch/x86/platform/sfi/sfi.c | 2 +-
7 files changed, 63 insertions(+), 7 deletions(-)
--
Thanks.
HATAYAMA, Daisuke
next reply other threads:[~2012-10-16 4:35 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-16 4:35 HATAYAMA Daisuke [this message]
2012-10-16 4:35 ` [PATCH v1 1/2] x86, apic: Introduce boot_cpu_is_bsp indicating whether boot cpu is BSP or not HATAYAMA Daisuke
2012-10-16 4:35 ` [PATCH v1 2/2] x86, apic: Disable BSP if boot cpu is AP HATAYAMA Daisuke
2012-10-22 20:04 ` Eric W. Biederman
2012-10-22 20:16 ` H. Peter Anvin
2012-10-22 20:31 ` Eric W. Biederman
2012-10-22 20:33 ` H. Peter Anvin
2012-10-22 20:38 ` H. Peter Anvin
2012-10-22 20:43 ` Eric W. Biederman
2012-10-22 20:47 ` H. Peter Anvin
2012-10-22 21:29 ` Eric W. Biederman
2012-10-23 0:35 ` H. Peter Anvin
2012-10-26 3:24 ` HATAYAMA Daisuke
2012-10-26 4:13 ` Eric W. Biederman
2013-03-11 1:07 ` HATAYAMA Daisuke
2013-03-11 2:13 ` HATAYAMA Daisuke
2013-03-11 4:11 ` H. Peter Anvin
2012-10-16 4:51 ` [PATCH v1 0/2] " Yu, Fenghua
2012-10-16 5:03 ` HATAYAMA Daisuke
2012-10-16 5:14 ` Yu, Fenghua
2012-10-16 6:38 ` HATAYAMA Daisuke
2012-10-22 16:02 ` H. Peter Anvin
2012-10-16 5:15 ` HATAYAMA Daisuke
2012-10-17 14:12 ` Vivek Goyal
2012-10-18 3:08 ` HATAYAMA Daisuke
2012-10-18 14:14 ` Vivek Goyal
2012-10-19 3:20 ` HATAYAMA Daisuke
2012-10-19 15:17 ` Vivek Goyal
2012-10-22 6:32 ` HATAYAMA Daisuke
2012-10-22 18:37 ` Vivek Goyal
2012-10-22 17:10 ` Michael Holzheu
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=20121016043357.20003.5885.stgit@localhost6.localdomain6 \
--to=d.hatayama@jp.fujitsu.com \
--cc=ebiederm@xmission.com \
--cc=fenghua.yu@intel.com \
--cc=grant.likely@secretlab.ca \
--cc=hpa@zytor.com \
--cc=kexec@lists.infradead.org \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rob.herring@calxeda.com \
--cc=tglx@linutronix.de \
--cc=vgoyal@redhat.com \
--cc=x86@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;
as well as URLs for NNTP newsgroup(s).