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
