From: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx> Subject: Re: [PATCH v1 2/2] x86, apic: Disable BSP if boot cpu is AP Date: Thu, 25 Oct 2012 21:13:25 -0700 > HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com> writes: > >> From: "H. Peter Anvin" <hpa at 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: <cut> >> 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, you have probably forgotten this work but I want to restart the work to allow multiple CPUs on the 2nd kernel. But on my investigation, I have a question about inconsistent states kdump framework assumes in the crash path on the 1st kernel. Now I'm re-investigating how to unset BSP flag on the 1st kernel in a safe manner. But then I must discuss possibility of BSP flag being set again after the unsetting of BSP. This includes firmware that assumes BSP flag is kept set throughtout system execution, but I noticed, fundamentally, it can happen even only with kernel code in the inconsistent state from the point where any bug happpens to before entering 2nd kernel. For example, some bug that causes buffer overrun can rewrite kdump code so some part of it be wrmsr but any other part is safe enough to boot 2nd kernel successfully... Although this is very low, but it must actually happen. Of course, we face the same situation if we put unsetting code in machine_shutdown() path, which is similarly not guaranteed to work well in inconsistent state. Different from kernel state and similar to any other device states, it seems to me that it's impossible to unset BSP flag in a safe manner together with inconsistent state kdump framework considers. Then, it seems to me that disabling BSP on 2nd kernel is a final resort. Thanks. HATAYAMA, Daisuke
