Re: [tip:x86/bsp-hotplug] x86, apic: Disable BSP if boot cpu is AP

[HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>]

(2013/11/12 4:54), H. Peter Anvin wrote:
> On 10/12/2013 10:42 AM, Ingo Molnar wrote:
>>
>> * H. Peter Anvin <hpa@zytor.com> wrote:
>>
>>> On 10/09/2013 04:16 PM, tip-bot for HATAYAMA Daisuke wrote:
>>>> Commit-ID:  1d79e607332d67d9132c176d99b5e7fabe1b6b7f
>>>> Gitweb:     http://git.kernel.org/tip/1d79e607332d67d9132c176d99b5e7fabe1b6b7f
>>>> Author:     HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
>>>> AuthorDate: Thu, 29 Aug 2013 18:28:04 +0900
>>>> Committer:  H. Peter Anvin <hpa@linux.intel.com>
>>>> CommitDate: Wed, 9 Oct 2013 15:41:11 -0700
>>>>
>>>> x86, apic: Disable BSP if boot cpu is AP
>>>
>>> This patch seems to trigger build failures in some configurations.
>>> Specifically:
>>>
>>> (.init.text+0x1307): undefined reference to `boot_cpu_is_bsp_init'
>>>
>>> Unfortunately I don't have the specific configuration which triggers the
>>> failure, as this was discovered by Fengguang's robot.
>>
>> I have triggered that too and have such a config, it's attached.
>
> Okay, thinking about this again, this patchset is in fact broken on:
>
> 1. Any configuration which has CONFIG_SMP=n and CONFIG_X86_UP_APIC=n.
>
> This is a built-time problem.
>
> 2. Any CPU which is old enough that MSR_IA32_APICBASE doesn't exist.
>
> This is a fatal runtime bug.
>
> 3. Any clustered solution which involves a third-party cluster
> controller such that MSR_IA32_APICBASE may not reflect the reality of
> the system.
>
> This is a less critical issue as "all" it ought to make happen is to
> disable some CPUs which didn't need it.
>
> Hatayama-san, you got this build bug report almost a month ago.  It
> looks like it is going to need a fair bit of cleanup, so I fear this is
> going to be dropped for v3.13.
>
> 	-hpa
>

Thanks for pointing out that. I think the first two issues has already been
fixed in v3 version. I've just posted v5 version a little time ago. BTW,
I changed the basic design at v4 where we specify the initial APIC ID of the
processor we want to disable in the kdump 2nd kernel from the the 1st kernel
through newly introduced disable_cpu_apicid kernel parameter; it might be
similar to the idea you described in the patch description of tip tree.

I don't know the third issue. Could you explain what kind of things can happen
on clustered system? Only IA32_APIC_BASE MSR is no longer trusted? Or are
there other things we can possibly no longer trust?

Also, could you explain what you suggest to deal with the issue in more detail?

-- 
Thanks.
HATAYAMA, Daisuke