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
