== Version 2 ==
Addresses Vivek's review comments:
1. Don't force numeric in awk script snipet.
2. Command line processing is moved from load_kernel to new function "prepare_cmdline." This new function is responsible for setting up the command line passed to KEXEC.
3. New function "append_cmdline" is added to append {argument,value} pair to command line if argument is not already present.
== Version 1 ==
A recent patch (https://lkml.org/lkml/2014/1/15/42) enables multiple processors in the crash kernel.
To do this safely the crash kernel needs to know which CPU was the 1st kernel BSP (bootstrap processor) so that the crash kernel will NOT send the BSP an INIT. If the crash kernel sends an INIT to the 1st kernel BSP, some systems may reset or hang.
The EFI spec doesn't require that any particular processor is chosen as the BSP and the CPU (and its apic id) can change from one boot to the next. Hence automating the selection of CPU to disable if the system would panic is desired.
This patch updates the kdumpctl script to get the "initial apicid" of CPU 0 in the first kernel and will pass this as the "disable_cpu_apicid=" arguement to kexec if it wasn't explicitly set in /etc/sysconfig/kdump KDUMP_COMMANDLINE_APPEND.
CPU 0 is chosen as it is the processor thats execute the OS initialization code and hence was the BSP as per x86 SDM (Vol 3a Section 8.4.)
See associated Red Hat Bugzilla(s) for additional background material:
https://bugzilla.redhat.com/show_bug.cgi?id=1059031 https://bugzilla.redhat.com/show_bug.cgi?id=980621 --- kdumpctl | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 54 insertions(+), 7 deletions(-)
diff --git a/kdumpctl b/kdumpctl index 46ae633..0a0bab1 100755 --- a/kdumpctl +++ b/kdumpctl @@ -41,6 +41,59 @@ function remove_cmdline_param() echo $cmdline }
+# +# This function returns the "initial apicid" of the +# boot cpu (cpu 0) if present. +# +function get_bootcpu_initial_apicid() +{ + awk ' \ + BEGIN { CPU = "-1"; } \ + $1=="processor" && $2==":" { CPU = $NF; } \ + CPU=="0" && /initial apicid/ { print $NF; } \ + ' \ + /proc/cpuinfo +} + +# +# This function appends argument "$2=$3" to string ($1) if not already present. +# +function append_cmdline() +{ + local cmdline=$1 + local newstr=${cmdline/$2/""} + + # unchanged str implies argument wasn't there + if [ "$cmdline" == "$newstr" ]; then + cmdline="${cmdline} ${2}=${3}" + fi + + echo $cmdline +} + +# This function performs a series of edits on the command line +function prepare_cmdline() +{ + local cmdline; + if [ -z "$KDUMP_COMMANDLINE" ]; then + cmdline=`cat /proc/cmdline` + else + cmdline=${KDUMP_COMMANDLINE} + fi + cmdline=`remove_cmdline_param "$cmdline" crashkernel hugepages hugepagesz` + + + cmdline="${cmdline} ${KDUMP_COMMANDLINE_APPEND}" + + local id=`get_bootcpu_initial_apicid` + if [ ! -z ${id} ] ; then + cmdline=`append_cmdline "${cmdline}" disable_cpu_apicid ${id}` + fi + + echo $cmdline +} + + function save_core() { coredir="/var/crash/`date +"%Y-%m-%d-%H:%M"`" @@ -244,13 +297,7 @@ function load_kdump() fi fi
- if [ -z "$KDUMP_COMMANDLINE" ] - then - KDUMP_COMMANDLINE=`cat /proc/cmdline` - fi - KDUMP_COMMANDLINE=`remove_cmdline_param "$KDUMP_COMMANDLINE" crashkernel hugepages hugepagesz` - - KDUMP_COMMANDLINE="${KDUMP_COMMANDLINE} ${KDUMP_COMMANDLINE_APPEND}" + KDUMP_COMMANDLINE=`prepare_cmdline`
$KEXEC $KEXEC_ARGS $standard_kexec_args \ --command-line="$KDUMP_COMMANDLINE" \
On Thu, Feb 20, 2014 at 06:09:30PM -0700, Jerry Hoemann wrote:
== Version 2 ==
Addresses Vivek's review comments:
Don't force numeric in awk script snipet.
Command line processing is moved from load_kernel to new function "prepare_cmdline." This new function is responsible for setting up the command line passed to KEXEC.
New function "append_cmdline" is added to append {argument,value} pair to command line if argument is not already present.
== Version 1 ==
A recent patch (https://lkml.org/lkml/2014/1/15/42) enables multiple processors in the crash kernel.
To do this safely the crash kernel needs to know which CPU was the 1st kernel BSP (bootstrap processor) so that the crash kernel will NOT send the BSP an INIT. If the crash kernel sends an INIT to the 1st kernel BSP, some systems may reset or hang.
The EFI spec doesn't require that any particular processor is chosen as the BSP and the CPU (and its apic id) can change from one boot to the next. Hence automating the selection of CPU to disable if the system would panic is desired.
This patch updates the kdumpctl script to get the "initial apicid" of CPU 0 in the first kernel and will pass this as the "disable_cpu_apicid=" arguement to kexec if it wasn't explicitly set in /etc/sysconfig/kdump KDUMP_COMMANDLINE_APPEND.
CPU 0 is chosen as it is the processor thats execute the OS initialization code and hence was the BSP as per x86 SDM (Vol 3a Section 8.4.)
See associated Red Hat Bugzilla(s) for additional background material:
https://bugzilla.redhat.com/show_bug.cgi?id=1059031 https://bugzilla.redhat.com/show_bug.cgi?id=980621
kdumpctl | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 54 insertions(+), 7 deletions(-)
Thanks Jerry. This version looks good to me.
Can you please test the disable_cpu_apicid override functionality by specifying it /etc/sysconfig/kdump and make sure it is working.
Acked-by: Vivek Goyal vgoyal@redhat.com
Thanks Vivek
diff --git a/kdumpctl b/kdumpctl index 46ae633..0a0bab1 100755 --- a/kdumpctl +++ b/kdumpctl @@ -41,6 +41,59 @@ function remove_cmdline_param() echo $cmdline }
+# +# This function returns the "initial apicid" of the +# boot cpu (cpu 0) if present. +# +function get_bootcpu_initial_apicid() +{
- awk ' \
- BEGIN { CPU = "-1"; } \
- $1=="processor" && $2==":" { CPU = $NF; } \
- CPU=="0" && /initial apicid/ { print $NF; } \
- ' \
- /proc/cpuinfo
+}
+# +# This function appends argument "$2=$3" to string ($1) if not already present. +# +function append_cmdline() +{
- local cmdline=$1
- local newstr=${cmdline/$2/""}
- # unchanged str implies argument wasn't there
- if [ "$cmdline" == "$newstr" ]; then
- cmdline="${cmdline} ${2}=${3}"
- fi
- echo $cmdline
+}
+# This function performs a series of edits on the command line +function prepare_cmdline() +{
- local cmdline;
- if [ -z "$KDUMP_COMMANDLINE" ]; then
cmdline=`cat /proc/cmdline`- else
cmdline=${KDUMP_COMMANDLINE}- fi
- cmdline=`remove_cmdline_param "$cmdline" crashkernel hugepages hugepagesz`
- cmdline="${cmdline} ${KDUMP_COMMANDLINE_APPEND}"
- local id=`get_bootcpu_initial_apicid`
- if [ ! -z ${id} ] ; then
cmdline=`append_cmdline "${cmdline}" disable_cpu_apicid ${id}`- fi
- echo $cmdline
+}
function save_core() { coredir="/var/crash/`date +"%Y-%m-%d-%H:%M"`" @@ -244,13 +297,7 @@ function load_kdump() fi fi
- if [ -z "$KDUMP_COMMANDLINE" ]
- then
KDUMP_COMMANDLINE=`cat /proc/cmdline`- fi
- KDUMP_COMMANDLINE=`remove_cmdline_param "$KDUMP_COMMANDLINE" crashkernel hugepages hugepagesz`
- KDUMP_COMMANDLINE="${KDUMP_COMMANDLINE} ${KDUMP_COMMANDLINE_APPEND}"
KDUMP_COMMANDLINE=`prepare_cmdline`
$KEXEC $KEXEC_ARGS $standard_kexec_args \ --command-line="$KDUMP_COMMANDLINE" \
-- 1.8.5.3
On Fri, Feb 21, 2014 at 08:14:10AM -0500, Vivek Goyal wrote:
On Thu, Feb 20, 2014 at 06:09:30PM -0700, Jerry Hoemann wrote:
== Version 2 ==
Addresses Vivek's review comments:
Don't force numeric in awk script snipet.
Command line processing is moved from load_kernel to new function "prepare_cmdline." This new function is responsible for setting up the command line passed to KEXEC.
New function "append_cmdline" is added to append {argument,value} pair to command line if argument is not already present.
== Version 1 ==
A recent patch (https://lkml.org/lkml/2014/1/15/42) enables multiple processors in the crash kernel.
To do this safely the crash kernel needs to know which CPU was the 1st kernel BSP (bootstrap processor) so that the crash kernel will NOT send the BSP an INIT. If the crash kernel sends an INIT to the 1st kernel BSP, some systems may reset or hang.
The EFI spec doesn't require that any particular processor is chosen as the BSP and the CPU (and its apic id) can change from one boot to the next. Hence automating the selection of CPU to disable if the system would panic is desired.
This patch updates the kdumpctl script to get the "initial apicid" of CPU 0 in the first kernel and will pass this as the "disable_cpu_apicid=" arguement to kexec if it wasn't explicitly set in /etc/sysconfig/kdump KDUMP_COMMANDLINE_APPEND.
CPU 0 is chosen as it is the processor thats execute the OS initialization code and hence was the BSP as per x86 SDM (Vol 3a Section 8.4.)
See associated Red Hat Bugzilla(s) for additional background material:
https://bugzilla.redhat.com/show_bug.cgi?id=1059031 https://bugzilla.redhat.com/show_bug.cgi?id=980621
kdumpctl | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 54 insertions(+), 7 deletions(-)
Thanks Jerry. This version looks good to me.
Can you please test the disable_cpu_apicid override functionality by specifying it /etc/sysconfig/kdump and make sure it is working.
Acked-by: Vivek Goyal vgoyal@redhat.com
Thanks Vivek
A. On a prototype system that exihibits the underlying problem w/ INIT to the 1st kernel BSP causing a hang.
B. System running RHEL 7.0 snap 6 plus kernel w/ Daisuke's patch
C. Using the modified kdumpctl script I sent yesterday.
D. Processor w/ APIC ID == 0 was deconfigured, so BSP has APIC ID == 2.
1) ran five crash dumps injecting error (echo c > /proc/sysrq-trigger) on random cpu successfully. crash kernel had nr_cpus=4. Crash dumps were successful.
2) Then configured /etc/sysconf/kdump to specify disable_cpu_apicid=0. Injected error on CPU 24. This time the crash kernel hung when bringing other processors on line.
The second test shows the crash kernel was looking to avoid INIT of APICID 0, not as it should of in the case of this system which has BSP w/ initial apicid of 2. (note, in development of the script I had an echo of the command line argument and tested this case to verify that explicit override was honored.)
I used RHEL 7.0 as I had access to RHEL 7 kernel that had Daisuke's patch applied (not sure about Fedora kernels in this respect.)
Both RHEL 7.0 and Fedora 20 had the same kdumpctl scripts prior to my modifications.
Jerry
(2014/02/22 3:52), Jerry Hoemann wrote:
On Fri, Feb 21, 2014 at 08:14:10AM -0500, Vivek Goyal wrote:
On Thu, Feb 20, 2014 at 06:09:30PM -0700, Jerry Hoemann wrote:
== Version 2 ==
Addresses Vivek's review comments:
Don't force numeric in awk script snipet.
Command line processing is moved from load_kernel to new function "prepare_cmdline." This new function is responsible for setting up the command line passed to KEXEC.
New function "append_cmdline" is added to append {argument,value} pair to command line if argument is not already present.
== Version 1 ==
A recent patch (https://lkml.org/lkml/2014/1/15/42) enables multiple processors in the crash kernel.
To do this safely the crash kernel needs to know which CPU was the 1st kernel BSP (bootstrap processor) so that the crash kernel will NOT send the BSP an INIT. If the crash kernel sends an INIT to the 1st kernel BSP, some systems may reset or hang.
The EFI spec doesn't require that any particular processor is chosen as the BSP and the CPU (and its apic id) can change from one boot to the next. Hence automating the selection of CPU to disable if the system would panic is desired.
This patch updates the kdumpctl script to get the "initial apicid" of CPU 0 in the first kernel and will pass this as the "disable_cpu_apicid=" arguement to kexec if it wasn't explicitly set in /etc/sysconfig/kdump KDUMP_COMMANDLINE_APPEND.
CPU 0 is chosen as it is the processor thats execute the OS initialization code and hence was the BSP as per x86 SDM (Vol 3a Section 8.4.)
See associated Red Hat Bugzilla(s) for additional background material:
https://bugzilla.redhat.com/show_bug.cgi?id=1059031 https://bugzilla.redhat.com/show_bug.cgi?id=980621
kdumpctl | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 54 insertions(+), 7 deletions(-)
Thanks Jerry. This version looks good to me.
Can you please test the disable_cpu_apicid override functionality by specifying it /etc/sysconfig/kdump and make sure it is working.
Acked-by: Vivek Goyal vgoyal@redhat.com
Thanks Vivek
A. On a prototype system that exihibits the underlying problem w/ INIT to the 1st kernel BSP causing a hang.
B. System running RHEL 7.0 snap 6 plus kernel w/ Daisuke's patch
C. Using the modified kdumpctl script I sent yesterday.
D. Processor w/ APIC ID == 0 was deconfigured, so BSP has APIC ID == 2.
ran five crash dumps injecting error (echo c > /proc/sysrq-trigger) on random cpu successfully. crash kernel had nr_cpus=4. Crash dumps were successful.
Then configured /etc/sysconf/kdump to specify disable_cpu_apicid=0. Injected error on CPU 24. This time the crash kernel hung when bringing other processors on line.
The second test shows the crash kernel was looking to avoid INIT of APICID 0, not as it should of in the case of this system which has BSP w/ initial apicid of 2. (note, in development of the script I had an echo of the command line argument and tested this case to verify that explicit override was honored.)
I used RHEL 7.0 as I had access to RHEL 7 kernel that had Daisuke's patch applied (not sure about Fedora kernels in this respect.)
Both RHEL 7.0 and Fedora 20 had the same kdumpctl scripts prior to my modifications.
Jerry
Thanks for your work, Jerry.
Vivek, do you plan to write configuration of nr_cpus in any document? Increasing nr_cpus increases amount of memory consumption in 2nd kernel, and particular kind of modules consumes memory in proportion to the number of logical cpus or local apic. It's cumbersome to automate configuring nr_cpus setting by script while estimating amount of memory. So for manual setting, notes on nr_cpus should be documented anywhere.
On Fri, Mar 14, 2014 at 06:58:55PM +0900, HATAYAMA Daisuke wrote:
[..]
Vivek, do you plan to write configuration of nr_cpus in any document? Increasing nr_cpus increases amount of memory consumption in 2nd kernel, and particular kind of modules consumes memory in proportion to the number of logical cpus or local apic. It's cumbersome to automate configuring nr_cpus setting by script while estimating amount of memory. So for manual setting, notes on nr_cpus should be documented anywhere.
I agree that we should document nr_cpus and its impact on kdump. Possibly we can put few lines in kexec-kdump-howto.txt. Would you like to send a patch. We can also talk of disable_apic_id usage in same paragraph.
Also I had a question. One reason you wanted to bring up multiple cpus in second kernel so that one can do compression in parallel on large machines.
How to use that functionality.
Thanks Vivek
On 02/20/14 at 06:09pm, Jerry Hoemann wrote:
== Version 2 ==
+# +# This function returns the "initial apicid" of the +# boot cpu (cpu 0) if present. +# +function get_bootcpu_initial_apicid() +{
- awk ' \
- BEGIN { CPU = "-1"; } \
- $1=="processor" && $2==":" { CPU = $NF; } \
- CPU=="0" && /initial apicid/ { print $NF; } \
- ' \
- /proc/cpuinfo
Hi Jerry,
How does it go with virtual machine? I didn't find the "initial apicid" on my kvm guest.
Baoquan Thanks
+}
+#
On Mon, Feb 24, 2014 at 10:38:00AM +0800, Baoquan He wrote:
On 02/20/14 at 06:09pm, Jerry Hoemann wrote:
== Version 2 ==
+# +# This function returns the "initial apicid" of the +# boot cpu (cpu 0) if present. +# +function get_bootcpu_initial_apicid() +{
- awk ' \
- BEGIN { CPU = "-1"; } \
- $1=="processor" && $2==":" { CPU = $NF; } \
- CPU=="0" && /initial apicid/ { print $NF; } \
- ' \
- /proc/cpuinfo
Hi Jerry,
How does it go with virtual machine? I didn't find the "initial apicid" on my kvm guest.
Baoquan Thanks
Hi Baoquan,
Without "initial apicid" the awk script will not match and a "disable_cpu_apicid=N" arguement won't be passed to the crash kernel.
This is actually good as the assumption that "CPU 0 == bsp" wouldn't hold in a virutal environment.
Howerver, this does mean that a kvm instance might still have difficultly specifying nr_cpus > 1 for crash kernel.
Longer term we should look into having something more explicit exported to user space saying which CPU is ths bsp. I know Vivek has mentioned this previously. If this information was available in both real hardware and virtual system, the above test could be modified.
Thanks for your feedback.
Jerry
On 02/24/14 at 12:22pm, Jerry Hoemann wrote:
On Mon, Feb 24, 2014 at 10:38:00AM +0800, Baoquan He wrote:
On 02/20/14 at 06:09pm, Jerry Hoemann wrote:
== Version 2 ==
Hi Jerry,
How does it go with virtual machine? I didn't find the "initial apicid" on my kvm guest.
Baoquan Thanks
Hi Baoquan,
Without "initial apicid" the awk script will not match and a "disable_cpu_apicid=N" arguement won't be passed to the crash kernel.
This is actually good as the assumption that "CPU 0 == bsp" wouldn't hold in a virutal environment.
Howerver, this does mean that a kvm instance might still have difficultly specifying nr_cpus > 1 for crash kernel.
Longer term we should look into having something more explicit exported to user space saying which CPU is ths bsp. I know Vivek has mentioned this previously. If this information was available in both real hardware and virtual system, the above test could be modified.
OK, this makes sense to me. Thanks Jerry.
Baoquan THanks
(2014/02/25 10:58), Baoquan He wrote:
On 02/24/14 at 12:22pm, Jerry Hoemann wrote:
On Mon, Feb 24, 2014 at 10:38:00AM +0800, Baoquan He wrote:
On 02/20/14 at 06:09pm, Jerry Hoemann wrote:
== Version 2 ==
Hi Jerry,
How does it go with virtual machine? I didn't find the "initial apicid" on my kvm guest.
Baoquan Thanks
Though you've already notice, this is the following issue. The patch has already been applied to latest RHEL7 kernel.
$ git log -1 a477c8594bee3bff639739c48258a8c737ab721e commit a477c8594bee3bff639739c48258a8c737ab721e Author: HATAYAMA Daisuke d.hatayama@jp.fujitsu.com Date: Tue Nov 5 02:15:48 2013 +0900
x86/cpu: Always print SMP information in /proc/cpuinfo
Currently show_cpuinfo_core() displays cpu core information only if the number of threads per a whole cores is 2 or larger.
However, this condition doesn't care about the number of sockets. For example, this condition doesn't hold on systems with two logical cpus consisting of two sockets and a single core on each socket - yet the topology information would be interesting to see in that case as well.
I don't know whether or not there are processors in real world by which such configurations are possible, but at least on vitual machine environments, such configuration can occur, typically when no explicit SMP information is provided in advance.
For example, on qemu/KVM, SMP information is specified via -smp command-line option, more specifically, its syntax is:
-smp n[,cores=cores][,threads=threads][,sockets=sockets][,maxcpus=maxcpus]
If this is not specified, qemu tells configuration with n-sockets, 1-core and 1-thread to the guest machine, on which guest, MP information is not displayed in /proc/cpuinfo.
I saw this situation on VMWare guest environment, too.
To fix this issue, this patch simply removes the condition because this information is useful even if there's only 1 thread.
Signed-off-by: HATAYAMA Daisuke d.hatayama@jp.fujitsu.com Cc: Vivek Goyal vgoyal@redhat.com Cc: H. Peter Anvin hpa@linux.intel.com Cc: Linus Torvalds torvalds@linux-foundation.org Cc: Andrew Morton akpm@linux-foundation.org Cc: Peter Zijlstra a.p.zijlstra@chello.nl Link: http://lkml.kernel.org/r/5277D644.4090707@jp.fujitsu.com Signed-off-by: Ingo Molnar mingo@kernel.org
Hi Baoquan,
Without "initial apicid" the awk script will not match and a "disable_cpu_apicid=N" arguement won't be passed to the crash kernel.
This is actually good as the assumption that "CPU 0 == bsp" wouldn't hold in a virutal environment.
As the above patch, this is irrelevant to virtual environment.
Howerver, this does mean that a kvm instance might still have difficultly specifying nr_cpus > 1 for crash kernel.
It's better to make kdumpctl fail if BSP is unknown and nr_cpus > 1 is specified in command line.
Longer term we should look into having something more explicit exported to user space saying which CPU is ths bsp. I know Vivek has mentioned this previously. If this information was available in both real hardware and virtual system, the above test could be modified.
This is easy. On BSP, BP bit on MSR is set, while on AP not set. Difference between BSP and AP is that only. So, it's enough to indicate BSP in /proc/cpuinfo if BP bit is set to the cpu.
Hi HATAYAMA,
Thanks for telling. I tested it on my KVM with 4 cpus, kernel is 3.10.0-110.el7.x86_64, the "nr_cpus=1" is erased, dumping is working very well.
I have to say this is awesome. Up to now the long-term disrupting multi-cpus problem has been solved. I guess next will be the performance improvement trying, especially the dumping splitting and running on multi-cpus simultaneously.
Thank you guys hard working on this issue.
Thanks Baoquan
On 03/14/14 at 07:33pm, HATAYAMA Daisuke wrote:
(2014/02/25 10:58), Baoquan He wrote:
On 02/24/14 at 12:22pm, Jerry Hoemann wrote:
On Mon, Feb 24, 2014 at 10:38:00AM +0800, Baoquan He wrote:
On 02/20/14 at 06:09pm, Jerry Hoemann wrote:
== Version 2 ==
Hi Jerry,
How does it go with virtual machine? I didn't find the "initial apicid" on my kvm guest.
Baoquan Thanks
Though you've already notice, this is the following issue. The patch has already been applied to latest RHEL7 kernel.
$ git log -1 a477c8594bee3bff639739c48258a8c737ab721e commit a477c8594bee3bff639739c48258a8c737ab721e Author: HATAYAMA Daisuke d.hatayama@jp.fujitsu.com Date: Tue Nov 5 02:15:48 2013 +0900
x86/cpu: Always print SMP information in /proc/cpuinfo Currently show_cpuinfo_core() displays cpu core information only if the number of threads per a whole cores is 2 or larger. However, this condition doesn't care about the number of sockets. For example, this condition doesn't hold on systems with two logical cpus consisting of two sockets and a single core on each socket - yet the topology information would be interesting to see in that case as well. I don't know whether or not there are processors in real world by which such configurations are possible, but at least on vitual machine environments, such configuration can occur, typically when no explicit SMP information is provided in advance. For example, on qemu/KVM, SMP information is specified via -smp command-line option, more specifically, its syntax is: -smp n[,cores=cores][,threads=threads][,sockets=sockets][,maxcpus=maxcpus] If this is not specified, qemu tells configuration with n-sockets, 1-core and 1-thread to the guest machine, on which guest, MP information is not displayed in /proc/cpuinfo. I saw this situation on VMWare guest environment, too. To fix this issue, this patch simply removes the condition because this information is useful even if there's only 1 thread. Signed-off-by: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: H. Peter Anvin <hpa@linux.intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/5277D644.4090707@jp.fujitsu.com Signed-off-by: Ingo Molnar <mingo@kernel.org>Hi Baoquan,
Without "initial apicid" the awk script will not match and a "disable_cpu_apicid=N" arguement won't be passed to the crash kernel.
This is actually good as the assumption that "CPU 0 == bsp" wouldn't hold in a virutal environment.
As the above patch, this is irrelevant to virtual environment.
Howerver, this does mean that a kvm instance might still have difficultly specifying nr_cpus > 1 for crash kernel.
It's better to make kdumpctl fail if BSP is unknown and nr_cpus > 1 is specified in command line.
Longer term we should look into having something more explicit exported to user space saying which CPU is ths bsp. I know Vivek has mentioned this previously. If this information was available in both real hardware and virtual system, the above test could be modified.
This is easy. On BSP, BP bit on MSR is set, while on AP not set. Difference between BSP and AP is that only. So, it's enough to indicate BSP in /proc/cpuinfo if BP bit is set to the cpu.
-- Thanks. HATAYAMA, Daisuke
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
-
Baoquan He -
HATAYAMA Daisuke -
Jerry Hoemann -
Vivek Goyal