All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Cc: hpa@zytor.com, len.brown@intel.com, fenghua.yu@intel.com,
	x86@kernel.org, kexec@lists.infradead.org,
	linux-kernel@vger.kernel.org, rob.herring@calxeda.com,
	grant.likely@secretlab.ca, tglx@linutronix.de, mingo@elte.hu,
	vgoyal@redhat.com
Subject: Re: [PATCH v1 2/2] x86, apic: Disable BSP if boot cpu is AP
Date: Thu, 25 Oct 2012 21:13:25 -0700	[thread overview]
Message-ID: <87r4oloopm.fsf@xmission.com> (raw)
In-Reply-To: <20121026.122406.13396329.d.hatayama@jp.fujitsu.com> (HATAYAMA Daisuke's message of "Fri, 26 Oct 2012 12:24:06 +0900 (JST)")

HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> writes:

> From: "H. Peter Anvin" <hpa@zytor.com>
> Subject: Re: [PATCH v1 2/2] x86, apic: Disable BSP if boot cpu is AP
> Date: Mon, 22 Oct 2012 17:35:47 -0700
>
>> On 10/22/2012 02:29 PM, Eric W. Biederman wrote:
>>>>
>>>> As I said, I thought Fenghua tried that but it didn't work,
>>>> experimentally.
>>>
>>> Fair enough.  You described the problem with clearing bit 8 in a weird
>>> way.
>>>
>>> If the best we can muster are fuzzy memories it may be worth
>>> revisiting.
>>> Perhaps it works on enough cpu models to be interesting.
>>>
>> 
>> It isn't fuzzy memories... this was done as late as 1-2 months ago.  I
>> just don't know the details.
>> 
>> Fenghua, could you help fill us in?
>> 
>
> I overlooked completely the fact that BSP flag is rewritable.
>
> I tried Eric's suggestion using attached test programs and saw it
> worked fine at least on the three cpus around me below:
>
> - Intel(R) Xeon(R) CPU E7- 4820  @ 2.00GHz
> - Intel(R) Xeon(R) CPU E7- 8870  @ 2.40GHz
> - Intel(R) Xeon(TM) CPU 1.80GHz
>   - 32 bits CPU
>
> Next I found the description about this in 8.4.2, IASDM Vol.3:
>
>   The MP initialization protocol imposes the following requirements
>   and restrictions on the system:
>
>   * The MP protocol is executed only after a power-up or RESET. If the
>     MP protocol has completed and a BSP is chosen, subsequent INITs
>     (either to a specific processor or system wide) do not cause the
>     MP protocol to be repeated. Instead, each logical processor
>     examines its BSP flag (in the IA32_APIC_BASE MSR) to determine
>     whether it should execute the BIOS boot-strap code (if it is the
>     BSP) or enter a wait-for-SIPI state (if it is an AP).
>
> So this is no longer undocumented behaviour for recent cpus, I think.

The underdocumented bit is the ability to clear the flag.
And of course these are processor specific registers.

> Considering these, I'll make a patch to clear BSP flag at appropreate
> position in kernel boot-up code. OTOH, according to the discussion, it
> was reported that clearing BSP flag affected some BIOSes. To deal with
> this, I'll prepare a kernel option to decide whether to clear BSP flag
> or not.
>
> Does anyone have any comments now? Or please comment after I submit a
> new patch.

I think you are on right track with preparing some patches, and this
certainly looks like worth experimenting with.

At least for i386 the code need to verify you have a cpu new enough to
have an APIC_BASE_MSR, but I don't think that is going to be hard.

Eric

WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Cc: len.brown@intel.com, fenghua.yu@intel.com, x86@kernel.org,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	rob.herring@calxeda.com, grant.likely@secretlab.ca,
	hpa@zytor.com, tglx@linutronix.de, mingo@elte.hu,
	vgoyal@redhat.com
Subject: Re: [PATCH v1 2/2] x86, apic: Disable BSP if boot cpu is AP
Date: Thu, 25 Oct 2012 21:13:25 -0700	[thread overview]
Message-ID: <87r4oloopm.fsf@xmission.com> (raw)
In-Reply-To: <20121026.122406.13396329.d.hatayama@jp.fujitsu.com> (HATAYAMA Daisuke's message of "Fri, 26 Oct 2012 12:24:06 +0900 (JST)")

HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> writes:

> From: "H. Peter Anvin" <hpa@zytor.com>
> Subject: Re: [PATCH v1 2/2] x86, apic: Disable BSP if boot cpu is AP
> Date: Mon, 22 Oct 2012 17:35:47 -0700
>
>> On 10/22/2012 02:29 PM, Eric W. Biederman wrote:
>>>>
>>>> As I said, I thought Fenghua tried that but it didn't work,
>>>> experimentally.
>>>
>>> Fair enough.  You described the problem with clearing bit 8 in a weird
>>> way.
>>>
>>> If the best we can muster are fuzzy memories it may be worth
>>> revisiting.
>>> Perhaps it works on enough cpu models to be interesting.
>>>
>> 
>> It isn't fuzzy memories... this was done as late as 1-2 months ago.  I
>> just don't know the details.
>> 
>> Fenghua, could you help fill us in?
>> 
>
> I overlooked completely the fact that BSP flag is rewritable.
>
> I tried Eric's suggestion using attached test programs and saw it
> worked fine at least on the three cpus around me below:
>
> - Intel(R) Xeon(R) CPU E7- 4820  @ 2.00GHz
> - Intel(R) Xeon(R) CPU E7- 8870  @ 2.40GHz
> - Intel(R) Xeon(TM) CPU 1.80GHz
>   - 32 bits CPU
>
> Next I found the description about this in 8.4.2, IASDM Vol.3:
>
>   The MP initialization protocol imposes the following requirements
>   and restrictions on the system:
>
>   * The MP protocol is executed only after a power-up or RESET. If the
>     MP protocol has completed and a BSP is chosen, subsequent INITs
>     (either to a specific processor or system wide) do not cause the
>     MP protocol to be repeated. Instead, each logical processor
>     examines its BSP flag (in the IA32_APIC_BASE MSR) to determine
>     whether it should execute the BIOS boot-strap code (if it is the
>     BSP) or enter a wait-for-SIPI state (if it is an AP).
>
> So this is no longer undocumented behaviour for recent cpus, I think.

The underdocumented bit is the ability to clear the flag.
And of course these are processor specific registers.

> Considering these, I'll make a patch to clear BSP flag at appropreate
> position in kernel boot-up code. OTOH, according to the discussion, it
> was reported that clearing BSP flag affected some BIOSes. To deal with
> this, I'll prepare a kernel option to decide whether to clear BSP flag
> or not.
>
> Does anyone have any comments now? Or please comment after I submit a
> new patch.

I think you are on right track with preparing some patches, and this
certainly looks like worth experimenting with.

At least for i386 the code need to verify you have a cpu new enough to
have an APIC_BASE_MSR, but I don't think that is going to be hard.

Eric

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2012-10-26  4:13 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-16  4:35 [PATCH v1 0/2] x86, apic: Disable BSP if boot cpu is AP HATAYAMA Daisuke
2012-10-16  4:35 ` HATAYAMA Daisuke
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   ` HATAYAMA Daisuke
2012-10-16  4:35 ` [PATCH v1 2/2] x86, apic: Disable BSP if boot cpu is AP HATAYAMA Daisuke
2012-10-16  4:35   ` HATAYAMA Daisuke
2012-10-22 20:04   ` Eric W. Biederman
2012-10-22 20:04     ` Eric W. Biederman
2012-10-22 20:16     ` H. Peter Anvin
2012-10-22 20:16       ` H. Peter Anvin
2012-10-22 20:31       ` Eric W. Biederman
2012-10-22 20:31         ` Eric W. Biederman
2012-10-22 20:33         ` H. Peter Anvin
2012-10-22 20:33           ` H. Peter Anvin
2012-10-22 20:38           ` H. Peter Anvin
2012-10-22 20:38             ` H. Peter Anvin
2012-10-22 20:43           ` Eric W. Biederman
2012-10-22 20:43             ` Eric W. Biederman
2012-10-22 20:47             ` H. Peter Anvin
2012-10-22 20:47               ` H. Peter Anvin
2012-10-22 21:29               ` Eric W. Biederman
2012-10-22 21:29                 ` Eric W. Biederman
2012-10-23  0:35                 ` H. Peter Anvin
2012-10-23  0:35                   ` H. Peter Anvin
2012-10-26  3:24                   ` HATAYAMA Daisuke
2012-10-26  3:24                     ` HATAYAMA Daisuke
2012-10-26  4:13                     ` Eric W. Biederman [this message]
2012-10-26  4:13                       ` Eric W. Biederman
2013-03-11  1:07                       ` HATAYAMA Daisuke
2013-03-11  1:07                         ` HATAYAMA Daisuke
2013-03-11  2:13                         ` HATAYAMA Daisuke
2013-03-11  2:13                           ` HATAYAMA Daisuke
2013-03-11  4:11                           ` H. Peter Anvin
2013-03-11  4:11                             ` H. Peter Anvin
2012-10-16  4:51 ` [PATCH v1 0/2] " Yu, Fenghua
2012-10-16  4:51   ` Yu, Fenghua
2012-10-16  5:03   ` HATAYAMA Daisuke
2012-10-16  5:03     ` HATAYAMA Daisuke
2012-10-16  5:14     ` Yu, Fenghua
2012-10-16  5:14       ` Yu, Fenghua
2012-10-16  6:38       ` HATAYAMA Daisuke
2012-10-16  6:38         ` HATAYAMA Daisuke
2012-10-22 16:02         ` H. Peter Anvin
2012-10-22 16:02           ` H. Peter Anvin
2012-10-16  5:15     ` HATAYAMA Daisuke
2012-10-16  5:15       ` HATAYAMA Daisuke
2012-10-17 14:12 ` Vivek Goyal
2012-10-17 14:12   ` Vivek Goyal
2012-10-18  3:08   ` HATAYAMA Daisuke
2012-10-18  3:08     ` HATAYAMA Daisuke
2012-10-18 14:14     ` Vivek Goyal
2012-10-18 14:14       ` Vivek Goyal
2012-10-19  3:20       ` HATAYAMA Daisuke
2012-10-19  3:20         ` HATAYAMA Daisuke
2012-10-19 15:17         ` Vivek Goyal
2012-10-19 15:17           ` Vivek Goyal
2012-10-22  6:32           ` HATAYAMA Daisuke
2012-10-22  6:32             ` HATAYAMA Daisuke
2012-10-22 18:37             ` Vivek Goyal
2012-10-22 18:37               ` Vivek Goyal
2012-10-22 17:10           ` Michael Holzheu
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=87r4oloopm.fsf@xmission.com \
    --to=ebiederm@xmission.com \
    --cc=d.hatayama@jp.fujitsu.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 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.