Re: [PATCH v4 0/3] x86, apic, kexec: Add disable_cpu_apic kernelparameter

From: HATAYAMA Daisuke
Date: Wed Oct 30 2013 - 05:51:30 EST

(2013/10/30 15:06), Baoquan He wrote:
On 10/30/13 at 09:44am, HATAYAMA Daisuke wrote:
(2013/10/29 23:21), Baoquan He wrote:

I am reviewing this patchset, and found there's a cpu0 hotplug feature
posted by intel which we can borrow an idea from. In that implementation,
CPU0 is waken up by nmi not INIT to avoid the realmode bootstrap code
execution. I tried it by below patch which includes one line of change.

By console printing, I got the boot cpu is always 0(namely cpu=0),
however the apicid related to each processor keeps the same as in 1st
kernel. In my HP Z420 machine, the apicid for BSP is 0, so I just make a
test patch which depends on the fact that apicid for BSP is 0. Maybe
generally the apicid for BSP can't be guaranteed, then passing it from
1st kernel to 2nd kernel in cmdline is very helpful, just as you have
done for disable_cpu_apic.

On my HP z420, I add nr_cpus=4 in /etc/sysconfig/kdump, and then execute
below command, then 3 APs (1 boot cpu and 2 AP) can be waken up
correctly, but BSP failed because NMI received for unknown reason 21 on
CPU0. I think I need further check why BSP failed to wake up by nmi. But
3 processors are brought up successfully and kdump is successful too.

sudo taskset -c 1 sh -c "echo c >/proc/sysrq-trigger"

[ 0.296831] smpboot: Booting Node 0, Processors # 1
[ 0.302095]
*****************************************************cpu=1, apicid=0, wakeup_cpu_via_init_nmi
[ 0.311942] cpu=1, apicid=0, register_nmi_handlercpu=1, apicid=0, wakeup_secondary_cpu_via_nmi
[ 0.320826] Uhhuh. NMI received for unknown reason 21 on CPU 0.
[ 0.327129] Do you have a strange power saving mode enabled?
[ 0.333858] Dazed and confused, but trying to continue
[ 0.339290] cpu=1, apicid=0, wakeup_cpu_via_init_nmi
[ 2.409099] Uhhuh. NMI received for unknown reason 21 on CPU 0.
[ 2.415393] Do you have a strange power saving mode enabled?
[ 2.421142] Dazed and confused, but trying to continue
[ 5.379519] smpboot: CPU1: Not responding
[ 5.383692] NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter.

We've already discussed this approach and concluded this is not applicable
to our issue.

The reason is:

- The cpu0-hotplugging approach assumes BSP to be halting before initiating
NMI to it while in our case, BSP is halting in the 1st kernel or is
running in arbitrary position of the 1st kernel in catastrophic state.

- In general, NMI modifies stack, which means if throwing NMI to the BSP
in the 1st kernel, stack on the 1st kernel is modified. It's unpermissible
from kdump's perspective.


All right. I didn't think of the stack issues NMI will bring. In fact
without this NMI stack problem, using CPU0 Hotplug as a base and sending
nmi to bsp will be good, because BSP failure can be acceptable, then
(N-1)cpus can be used. Later on if possible the contexts modifying can
be changed to let BSP wake up correctly. After all, from the user's
point of view, multiple cpus can be waken up, why not waking up all cpus
including BSP.

Anyway, this issue has been discussed so long time, and it will be great
to run multiple cpus in 2nd kernel. This evolution may be like CPU0 Hotplug,
they let cpus except of BSP hot plug available, then hanle the last cpu -
the BSP finally. From this perspective, I like your patch and hope it
can be merged asap.

Considering again, I'm now beginning with thinking that making CPU halting
in the 1st kernel to execute the 2nd kernel's NMI handler is impossible.

The address of IDT is saved in IDTR and this is a per-cpu register, and
value of IDTR in the 2nd kernel and the one in the 1st kernel are different.
In other words, to wake up BSP from 2nd kernel using NMI, it's necessary to
tell the address of IDTR in the 2nd kernel to the BSP halting in the 1st


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at