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

[Petr Tesarik]

On Tue, 29 Oct 2013 09:53:57 +0900
HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com> wrote:

> (2013/10/25 20:05), Petr Tesarik wrote:
> > 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".
> >
> 
> You should look at initial apicid. Initial apicid is the value assigned
> during MP initialization and their values are unique while the values on
> local APIC ID registers vary at runtime.
> 
> If you say "apicid" line about ones in ACPI MADT or MP table, they are
> initial ones, although there's explicit "initial".
> 
> > Unfortunately, all my systems list the same value under "apicid" and
> > "initial apicid", so I don't know how to test.
> 
> You don't need to compare two kind of values at all. You have only to use
> initial apicid to identify target cpu beyond different component: BIOS,
> 1st kernel and 2nd kernel.

Thank you for the explanation. This was really helpful!

Petr T