[PATCH] x86, apic: Add unset_bsp parameter to unset BSP flag atboot time

[HATAYAMA Daisuke]

This is the 2nd step to make multiple CPUs runnable on the kdump 2nd
kernel. The 1st step is:

  [PATCH v1 0/2] x86, apic: Disable BSP if boot cpu is AP
  http://lists.infradead.org/pipermail/kexec/2012-October/006905.html

where I'm trying to disable BSP CPU if the boot CPU on the 2nd kernel
doesn't have MSR's BSP flag set. The problem is that there's no
gurantee that all the firmware puts the entry for BSP in the first
position.

Instead, this patch unsets BSP flag in the 1st kernel's boot
time. This logic is suggested by Eric Biederman. The unsetting is done
if unset_bsp kernel option is specified.

However, this is still an experimental patch. The unsetting BSP can
affect some kernel component, module or firmware that expect BSP flag
to be kept set throughtout runtime. In other words, the purpose of
this patch is to reveal whether there's actually such components in
these layers.

Note also that apart from the dependency to BSP flag of such
components, on inconsistent system state, it's already impossible to
treat this issue perfectly within kernel logic only since the issue
depends on processor, entity outside of the kernel.

For example, imagine the case where some buffer overrun happens and it
rewrites some bytes in the middle of machine_kexec() into rdmsr
instruction... This means that any CPUs including AP can have BSP flag
set at runtime.

In conclusion, we need to use multiple CPUs at the cost of loosing
some kind of the bugs kdump framework can cover now.

Test:

- Build on top of 3.9-rc3, x86_64.
- I used FUJITSU PRIMERGY RX600 S6. it looks working file for some
  hours.

Review points I expect:

- How to find components that depend on BSP flag? What kind of kernel
  operations are expecting BSP flag to be kept set?

- How to reach point for comprimise of this issue?

  I think there's no method to work well on every environment. So
  setting kernel parameter on each specific environemnt seems
  preferable.