From: Borislav Petkov <bp@alien8.de> To: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> Cc: ebiederm@xmission.com, vgoyal@redhat.com, akpm@linux-foundation.org, hpa@linux.intel.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, jingbai.ma@hp.com Subject: Re: [PATCH 2/2] x86, apic: Disable BSP if boot cpu is AP Date: Mon, 2 Sep 2013 09:13:18 +0200 [thread overview] Message-ID: <20130902071318.GA3406@x1.alien8.de> (raw) In-Reply-To: <5223F8DB.3040506@jp.fujitsu.com> On Mon, Sep 02, 2013 at 11:32:59AM +0900, HATAYAMA Daisuke wrote: > As you suggest, boot_cpu seems more understandable also to me. BTW, > please notice that it doesn't denote that the CPU we're booting on > currently, but that the CPU with BSP flag set. Hmm, by "BSP flag set" you mean it is the first LAPIC entry in the MADT, correct? At least this is the case when you set isbsp to true. Because, there's also the BSC flag in APIC_BAR (MSR 0x1b) which denotes the bootstrapping core on node 0. > In general, current code uses many terms to denote the cpu that is run > at kernel boot-up processing such as boot cpu, bsp, cpu0 and possibly > others since in usual situation, boot cpu is always BSP and assigned > to cpu0. But it is not the case in case of kexec. I'm using the word > bsp purposely in the isbsp to mean the CPU with BSP flag set. > > So I think it's better to use bsp_cpu here to denote the CPU with BSP > flag set. Right. > For the comment, how about the following one? > > /* > * In this case, boot cpu is AP. This can happen on > * kexec/kdump. Consider the case that crash happens on some > * AP and enters kdump 2nd kernel with the AP. > * > * Then, there's issue that if we send INIT to BSP, due to x86 > * hardware specification, it is forced to jump at BIOS init > * code and system hangs or resets immediately. > * > * To avoid the issue, we disable BSP. Then, there's no longer > * possbility to send INIT to BSP. > */ Yes, much better. Especially when looking down the road and people have forgotten what the whole fuss was about, a nice detailed comment is priceless. Thanks. -- Regards/Gruss, Boris.
WARNING: multiple messages have this Message-ID (diff)
From: Borislav Petkov <bp@alien8.de> To: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> Cc: jingbai.ma@hp.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, ebiederm@xmission.com, akpm@linux-foundation.org, hpa@linux.intel.com, vgoyal@redhat.com Subject: Re: [PATCH 2/2] x86, apic: Disable BSP if boot cpu is AP Date: Mon, 2 Sep 2013 09:13:18 +0200 [thread overview] Message-ID: <20130902071318.GA3406@x1.alien8.de> (raw) In-Reply-To: <5223F8DB.3040506@jp.fujitsu.com> On Mon, Sep 02, 2013 at 11:32:59AM +0900, HATAYAMA Daisuke wrote: > As you suggest, boot_cpu seems more understandable also to me. BTW, > please notice that it doesn't denote that the CPU we're booting on > currently, but that the CPU with BSP flag set. Hmm, by "BSP flag set" you mean it is the first LAPIC entry in the MADT, correct? At least this is the case when you set isbsp to true. Because, there's also the BSC flag in APIC_BAR (MSR 0x1b) which denotes the bootstrapping core on node 0. > In general, current code uses many terms to denote the cpu that is run > at kernel boot-up processing such as boot cpu, bsp, cpu0 and possibly > others since in usual situation, boot cpu is always BSP and assigned > to cpu0. But it is not the case in case of kexec. I'm using the word > bsp purposely in the isbsp to mean the CPU with BSP flag set. > > So I think it's better to use bsp_cpu here to denote the CPU with BSP > flag set. Right. > For the comment, how about the following one? > > /* > * In this case, boot cpu is AP. This can happen on > * kexec/kdump. Consider the case that crash happens on some > * AP and enters kdump 2nd kernel with the AP. > * > * Then, there's issue that if we send INIT to BSP, due to x86 > * hardware specification, it is forced to jump at BIOS init > * code and system hangs or resets immediately. > * > * To avoid the issue, we disable BSP. Then, there's no longer > * possbility to send INIT to BSP. > */ Yes, much better. Especially when looking down the road and people have forgotten what the whole fuss was about, a nice detailed comment is priceless. Thanks. -- Regards/Gruss, Boris. _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2013-09-02 7:13 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 [this message] 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 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=20130902071318.GA3406@x1.alien8.de \ --to=bp@alien8.de \ --cc=akpm@linux-foundation.org \ --cc=d.hatayama@jp.fujitsu.com \ --cc=ebiederm@xmission.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.