From: ebiederm@xmission.com (Eric W. Biederman) To: "H. Peter Anvin" <hpa@linux.intel.com> Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>, vgoyal@redhat.com, akpm@linux-foundation.org, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, jingbai.ma@hp.com Subject: Re: [PATCH 0/2] x86, apic: Disable BSP if boot cpu is AP Date: Thu, 29 Aug 2013 16:37:44 -0700 [thread overview] Message-ID: <8738ps131z.fsf@xmission.com> (raw) In-Reply-To: <521F5297.4070906@linux.intel.com> (H. Peter Anvin's message of "Thu, 29 Aug 2013 06:54:31 -0700") "H. Peter Anvin" <hpa@linux.intel.com> writes: > On 08/29/2013 02:27 AM, HATAYAMA Daisuke wrote: >> This is the patch series to address the issue that kdump 2nd kernel >> now fails to wake up multiple CPUs. > > Please explain the "now" in the above sentence. Is this a regression? > If so, what is its fimpact? This is not a regression. > Is this something that needs to go into 3.11 > as a post-rc7 change, which means it better be hyper-critical? No. This is something that does not need to go into 3.11. This situation is people who run machines of unreasonable size really would like to use multiple cpus when generating crash dumps. A practical problem with that desire is that sending a (startup? init? I forget which) IPI to a processor with the BSP flag sent triggers that processor to load code from 0xfffffff0 instead of the vector specified in the IPI. At which point the processor which jumped to 0xfffffff0 and is running BIOS code does not call into the kernel so never comes up which is unfortunate, and worse almost always triggers a soft reset by writing hardware registers. Which means the practical way to avoid this sort of thing is not to send init/startup IPIs to processors with the BSP bit set. Which MPtables and ACPI tables should denote as the boot processor. In a previous attack on this problem we explored if it was possible to clear the BSP bit and be able to use all processors but that does not work. I think it was actually your suggestion that we just skip the BSP. Anyway this long simmering issue has raised it's head again and we have iron-clad evidence that the only thing people can do is avoid the problem so this is a patchset to allow people who wind up in a situtation where they are not booting on the bootstrap processor to to avoid problems, and use as many of their other processors as possible. Which should make people with boxes of unusual size happy. Eric
WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman) To: "H. Peter Anvin" <hpa@linux.intel.com> Cc: kexec@lists.infradead.org, linux-kernel@vger.kernel.org, HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>, vgoyal@redhat.com, akpm@linux-foundation.org, jingbai.ma@hp.com Subject: Re: [PATCH 0/2] x86, apic: Disable BSP if boot cpu is AP Date: Thu, 29 Aug 2013 16:37:44 -0700 [thread overview] Message-ID: <8738ps131z.fsf@xmission.com> (raw) In-Reply-To: <521F5297.4070906@linux.intel.com> (H. Peter Anvin's message of "Thu, 29 Aug 2013 06:54:31 -0700") "H. Peter Anvin" <hpa@linux.intel.com> writes: > On 08/29/2013 02:27 AM, HATAYAMA Daisuke wrote: >> This is the patch series to address the issue that kdump 2nd kernel >> now fails to wake up multiple CPUs. > > Please explain the "now" in the above sentence. Is this a regression? > If so, what is its fimpact? This is not a regression. > Is this something that needs to go into 3.11 > as a post-rc7 change, which means it better be hyper-critical? No. This is something that does not need to go into 3.11. This situation is people who run machines of unreasonable size really would like to use multiple cpus when generating crash dumps. A practical problem with that desire is that sending a (startup? init? I forget which) IPI to a processor with the BSP flag sent triggers that processor to load code from 0xfffffff0 instead of the vector specified in the IPI. At which point the processor which jumped to 0xfffffff0 and is running BIOS code does not call into the kernel so never comes up which is unfortunate, and worse almost always triggers a soft reset by writing hardware registers. Which means the practical way to avoid this sort of thing is not to send init/startup IPIs to processors with the BSP bit set. Which MPtables and ACPI tables should denote as the boot processor. In a previous attack on this problem we explored if it was possible to clear the BSP bit and be able to use all processors but that does not work. I think it was actually your suggestion that we just skip the BSP. Anyway this long simmering issue has raised it's head again and we have iron-clad evidence that the only thing people can do is avoid the problem so this is a patchset to allow people who wind up in a situtation where they are not booting on the bootstrap processor to to avoid problems, and use as many of their other processors as possible. Which should make people with boxes of unusual size happy. Eric _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2013-08-29 23:38 UTC|newest] Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-08-29 9:27 [PATCH 0/2] x86, apic: Disable BSP if boot cpu is AP HATAYAMA Daisuke 2013-08-29 9:27 ` HATAYAMA Daisuke 2013-08-29 9:27 ` [PATCH 1/2] x86, apic: Add boot_cpu_is_bsp() to check if boot cpu is BSP HATAYAMA Daisuke 2013-08-29 9:27 ` HATAYAMA Daisuke 2013-10-09 23:15 ` [tip:x86/bsp-hotplug] " tip-bot for HATAYAMA Daisuke 2013-08-29 9:28 ` [PATCH 2/2] x86, apic: Disable BSP if boot cpu is AP HATAYAMA Daisuke 2013-08-29 9:28 ` HATAYAMA Daisuke 2013-08-31 5:22 ` Borislav Petkov 2013-08-31 5:22 ` Borislav Petkov 2013-09-02 2:32 ` HATAYAMA Daisuke 2013-09-02 2:32 ` HATAYAMA Daisuke 2013-09-02 7:13 ` Borislav Petkov 2013-09-02 7:13 ` Borislav Petkov 2013-09-02 9:42 ` HATAYAMA Daisuke 2013-09-02 9:42 ` HATAYAMA Daisuke 2013-09-04 6:12 ` Borislav Petkov 2013-09-04 6:12 ` Borislav Petkov 2013-09-09 6:18 ` HATAYAMA Daisuke 2013-09-09 6:18 ` HATAYAMA Daisuke 2013-10-09 23:16 ` [tip:x86/bsp-hotplug] " tip-bot for HATAYAMA Daisuke 2013-10-12 17:31 ` H. Peter Anvin 2013-10-12 17:42 ` Ingo Molnar 2013-11-11 19:54 ` H. Peter Anvin 2013-11-12 10:20 ` HATAYAMA Daisuke 2013-11-12 15:35 ` H. Peter Anvin 2013-08-29 13:54 ` [PATCH 0/2] " H. Peter Anvin 2013-08-29 13:54 ` H. Peter Anvin 2013-08-29 23:37 ` Eric W. Biederman [this message] 2013-08-29 23:37 ` Eric W. Biederman 2013-08-30 12:48 ` Vivek Goyal 2013-08-30 12:48 ` Vivek Goyal 2013-08-29 23:51 ` HATAYAMA Daisuke 2013-08-29 23:51 ` HATAYAMA Daisuke 2013-08-30 15:43 ` H. Peter Anvin 2013-08-30 15:43 ` H. Peter Anvin 2013-10-09 20:20 ` Vivek Goyal 2013-10-09 20:20 ` Vivek Goyal 2013-10-14 9:03 ` Petr Tesarik 2013-10-14 9:03 ` Petr Tesarik
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=8738ps131z.fsf@xmission.com \ --to=ebiederm@xmission.com \ --cc=akpm@linux-foundation.org \ --cc=d.hatayama@jp.fujitsu.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: linkBe 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.