[PATCH v4 0/3] x86, apic, kexec: Add disable_cpu_apic kernel parameter

[Petr Tesarik]

On Thu, 24 Oct 2013 10:42:12 +0900
HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com> wrote:

> (2013/10/24 0:51), Vivek Goyal wrote:
> > On Wed, Oct 23, 2013 at 09:05:06AM +0900, HATAYAMA Daisuke wrote:
> >
> > [..]
> >>> Do you literally mean a human at each boot will have to configure
> >>> the kdump configuration files for passing disable_cpu_apic?
> >>> Or do you envision the setting of disable_cpu_apic being put into
> >>> the kdump initialization scripts?
> >>>
> >>> thanks
> >>>
> >>> Jerry
> >>
> >> Nearer to the former case, but this is not what a human should do. It's
> >> a cumbersome task. I think, on fedora/RHEL system for example, kdump
> >> service should check at each boot automatically.
> >
> > Hi Hatayama,
> >
> > So what information should I look for to prepare disable_cpu_apic=X in
> > kdump script?
> >
> > Is BSP processor info exported to user space somewhere? Or assuming that
> > processor 0 is BSP and corresponding apicid should be disabled in kdump
> > kernel is good enough?
> >
> 
> Yes, this patch set assumes that the processor 0 is BSP and there's no
> other BSP. Because this patch cares about only one BSP processor,
> the disabled_cpu_apicid variable has unsigned int, not mask.
> 
> I think this assumption is reasonable since doing it rigorously requires
> additional processing between 1st and 2nd kernels just as I explained in
> previous mail.
> 
> > I am looking at /proc/cpuinfo and following 3 fields seem interesting.
> >
> > processor: 0
> > apicid		: 0
> > initial apicid	: 0
> >
> > What's the difference between apicid and "initial apicid". I guess
> > initial apicid reflects the apicid number as set by firmware and then
> > kernel can overwrite it and new number would be reflected in "apicid"?
> >
> > If that's the case, then I guess we should be looking at "apicid" of
> > processor "0" and set that in disable_cpu_apic? Because that's the
> > number kdump kernel  boot should see in apic upon boot.
> >
> 
> Yes, that's fully correct, and please see 10.4.6 Local APIC ID in Intel SPG
> for details.
> 
> BTW, we can use cpuid instruction in user-space, too. It might be more
> flexible to use cpuid than looking up /proc/cpuinfo.
> 
> Also, there's one corner case that if we hot-remove cpu0, we cannot
> look up /proc/cpuinfo to get cpu0 information since /proc/cpunifo displays
> *online* cpus only. We cannot use even cpuid instruction for offline cpu.
> So, to address this corner case, we need to prepare new interface to see
> cpu0 initial apicid which is always available.
> 
> My idea is for example to introduce the following file in sysfs:
> 
>    /sys/devices/system/cpu/cpu0/initial_apicid

I'm confused. So, should I look at the "initial apicid" line, or the
"apicid" line in /proc/cpuinfo? Your previous mail suggested the
"apicid" line, but then it's confusing to call the sysfs file
"initial_apicid".

Unfortunately, all my systems list the same value under "apicid" and
"initial apicid", so I don't know how to test.

Petr Tesarik