From: Borislav Petkov <bp@alien8.de>
To: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Cc: hpa@linux.intel.com, ebiederm@xmission.com, vgoyal@redhat.com,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
akpm@linux-foundation.org, fengguang.wu@intel.com,
jingbai.ma@hp.com
Subject: Re: [PATCH v5 2/3] x86, apic: Add disable_cpu_apicid kernel parameter
Date: Tue, 12 Nov 2013 11:44:23 +0100 [thread overview]
Message-ID: <20131112104423.GB12849@pd.tnic> (raw)
In-Reply-To: <20131112095158.4902.75396.stgit@localhost6.localdomain6>
On Tue, Nov 12, 2013 at 06:51:58PM +0900, HATAYAMA Daisuke wrote:
> Add disable_cpu_apicid kernel parameter. To use this kernel parameter,
> specify an initial APIC ID of the corresponding CPU you want to
> disable.
>
> This is mostly used for the kdump 2nd kernel to disable BSP to wake up
> multiple CPUs without causing system reset or hang due to sending INIT
> from AP to BSP.
>
> Kdump users first figure out initial APIC ID of the BSP, CPU0 in the
> 1st kernel, for example from /proc/cpuinfo and then set up this kernel
> parameter for the 2nd kernel using the obtained APIC ID.
>
> However, doing this procedure at each boot time manually is awkward,
> which should be automatically done by user-land service scripts, for
> example, kexec-tools on fedora/RHEL distributions.
>
> This design is more flexible than disabling BSP in kernel boot time
> automatically in that in kernel boot time we have no choice but
> referring to ACPI/MP table to obtain initial APIC ID for BSP, meaning
> that the method is not applicable to the systems without such BIOS
> tables.
>
> One assumption behind this design is that users get initial APIC ID of
> the BSP in still healthy state and so BSP is uniquely kept in
> CPU0. Thus, through the kernel parameter, only one initial APIC ID can
> be specified.
>
> Signed-off-by: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
> ---
> arch/x86/kernel/apic/apic.c | 29 +++++++++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
>
> diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
> index b60ad92..075bf23 100644
> --- a/arch/x86/kernel/apic/apic.c
> +++ b/arch/x86/kernel/apic/apic.c
> @@ -78,6 +78,13 @@ unsigned int max_physical_apicid;
> physid_mask_t phys_cpu_present_map;
>
> /*
> + * Processor to be disabled specified by kernel parameter
> + * disable_cpu_apicid=<int>, mostly used for the kdump 2nd kernel to
> + * avoid undefined behaviour caused by sending INIT from AP to BSP.
> + */
> +unsigned int disabled_cpu_apicid = BAD_APICID;
> +
> +/*
> * Map cpu index to physical APIC ID
> */
> DEFINE_EARLY_PER_CPU_READ_MOSTLY(u16, x86_cpu_to_apicid, BAD_APICID);
> @@ -2117,6 +2124,19 @@ void generic_processor_info(int apicid, int version)
> bool boot_cpu_detected = physid_isset(boot_cpu_physical_apicid,
> phys_cpu_present_map);
>
> + if (disabled_cpu_apicid != BAD_APICID &&
> + disabled_cpu_apicid != boot_cpu_physical_apicid &&
> + disabled_cpu_apicid == apicid) {
> + int thiscpu = num_processors + disabled_cpus;
> +
> + pr_warning("ACPI: Disable specified CPU."
> + " Processor %d/0x%x ignored.\n",
> + thiscpu, apicid);
How am I to parse this message - that 'thiscpu' is being disabled
currently? What does "Processor ... ignored" mean?
Why not just write:
ACPI: Disabling requested CPU %d (APIC ID: 0x%x)
and everyone knows what's happening?
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
next prev parent reply other threads:[~2013-11-12 10:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-12 9:51 [PATCH v5 0/3] x86, apic, kexec: Add disable_cpu_apic " HATAYAMA Daisuke
2013-11-12 9:51 ` [PATCH v5 1/3] x86, apic: add bsp_physical_apicid HATAYAMA Daisuke
2013-11-14 11:16 ` HATAYAMA Daisuke
2013-11-12 9:51 ` [PATCH v5 2/3] x86, apic: Add disable_cpu_apicid kernel parameter HATAYAMA Daisuke
2013-11-12 10:44 ` Borislav Petkov [this message]
2013-11-14 10:42 ` HATAYAMA Daisuke
2013-11-12 9:52 ` [PATCH v5 3/3] Documentation, x86, apic, kexec: " 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=20131112104423.GB12849@pd.tnic \
--to=bp@alien8.de \
--cc=akpm@linux-foundation.org \
--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 \
--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
all inboxes | Powered by JetHome®