From: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: fengguang.wu@intel.com, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org, bp@alien8.de,
ebiederm@xmission.com, akpm@linux-foundation.org,
hpa@linux.intel.com, jingbai.ma@hp.com
Subject: Re: [PATCH v7 1/2] x86, apic: Add disable_cpu_apicid kernel parameter
Date: Thu, 28 Nov 2013 09:18:18 +0900 [thread overview]
Message-ID: <52968BCA.4040803@jp.fujitsu.com> (raw)
In-Reply-To: <20131127151017.GI18706@redhat.com>
(2013/11/28 0:10), Vivek Goyal wrote:
> On Wed, Nov 27, 2013 at 11:00:48AM +0900, HATAYAMA Daisuke wrote:
>> Add disable_cpu_apicid kernel parameter. To use this kernel parameter,
>> specify an initial APIC ID of the corresponding CPU you want to
>> disable.
>>
>> This is mostly used for the kdump 2nd kernel to disable BSP to wake up
>> multiple CPUs without causing system reset or hang due to sending INIT
>> from AP to BSP.
>>
>> Kdump users first figure out initial APIC ID of the BSP, CPU0 in the
>> 1st kernel, for example from /proc/cpuinfo and then set up this kernel
>> parameter for the 2nd kernel using the obtained APIC ID.
>>
>> However, doing this procedure at each boot time manually is awkward,
>> which should be automatically done by user-land service scripts, for
>> example, kexec-tools on fedora/RHEL distributions.
>>
>> This design is more flexible than disabling BSP in kernel boot time
>> automatically in that in kernel boot time we have no choice but
>> referring to ACPI/MP table to obtain initial APIC ID for BSP, meaning
>> that the method is not applicable to the systems without such BIOS
>> tables.
>>
>> One assumption behind this design is that users get initial APIC ID of
>> the BSP in still healthy state and so BSP is uniquely kept in
>> CPU0. Thus, through the kernel parameter, only one initial APIC ID can
>> be specified.
>>
>> boot_cpu_physical_apicid is designed to have the apicid returned by
>> read_apic_id(). However, on some platforms, it is temporarilly
>> modified by the apicid reported as BSP through MP table. This function
>> is called with the modified boot_cpu_physical_apicid.
>>
>> On the platforms, boot_cpu_physical_apicid is always forced to be the
>> apicid of the BSP. Then, disabled_cpu_apicid kernel parameter doesn't
>> work well for apicids for APs.
>>
>> Here we leave improvement of handling boot_cpu_physical_apicid as
>> another work for now since the temporary modification is done on
>> differnet platforms and tests on each platform are required. As a
>> workaround, we directly update boot_cpu_physical_apicid by
>> read_apic_id().
>>
>> Signed-off-by: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
>> ---
>> arch/x86/kernel/apic/apic.c | 49 +++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 49 insertions(+)
>>
>> diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
>> index d278736..a94f618 100644
>> --- a/arch/x86/kernel/apic/apic.c
>> +++ b/arch/x86/kernel/apic/apic.c
>> @@ -75,6 +75,13 @@ unsigned int max_physical_apicid;
>> physid_mask_t phys_cpu_present_map;
>>
>> /*
>> + * Processor to be disabled specified by kernel parameter
>> + * disable_cpu_apicid=<int>, mostly used for the kdump 2nd kernel to
>> + * avoid undefined behaviour caused by sending INIT from AP to BSP.
>> + */
>> +unsigned int disabled_cpu_apicid = BAD_APICID;
>> +
>> +/*
>> * Map cpu index to physical APIC ID
>> */
>> DEFINE_EARLY_PER_CPU_READ_MOSTLY(u16, x86_cpu_to_apicid, BAD_APICID);
>> @@ -2111,9 +2118,42 @@ void disconnect_bsp_APIC(int virt_wire_setup)
>> int generic_processor_info(int apicid, int version)
>> {
>> int cpu, max = nr_cpu_ids;
>> + /*
>> + * boot_cpu_physical_apicid is designed to have the apicid
>> + * returned by read_apic_id(). However, on some platforms, it
>> + * is temporarilly modified by the apicid reported as BSP
>> + * through MP table. Concretely:
>> + *
>> + * - arch/x86/kernel/mpparse.c: MP_processor_info()
>> + * - arch/x86/mm/amdtopology.c: amd_numa_init()
>> + * - arch/x86/platform/visws/visws_quirks.c: MP_processor_info()
>> + *
>> + * This function is executed with the modified
>> + * boot_cpu_physical_apicid. So, disabled_cpu_apicid kernel
>> + * parameter doesn't work.
>> + *
>> + * Since fixing handling of boot_cpu_physical_apicid requires
>> + * another discussion and tests on each platform, we leave it
>> + * for now and here we use read_apic_id() directly by updating
>> + * global scope of boot_cpu_physical_id with the local one.
>> + */
>> + unsigned int boot_cpu_physical_apicid = read_apic_id();
>
> I think this is confusing. Why are you trying to define a local variable
> with same name as global variable. There is no need. I think if we
> simply put the comment there that why are we not making use of
> boot_cpu_physical_apicid, that is good enough and directly read
> the apic id.
>
> if (disabled_cpu_apicid != BAD_APICID &&
> disabled_cpu_apicid != read_apic_id() &&
> disabled_cpu_apicid == apicid) {
>
> }
>
Because there are also other occurrences of boot_cpu_physical_apicid in the
same function, and defining the local variable with the same name needs
one line only, and it's a temporary workaround change, I think it unnatural
to replace boot_cpu_physical_apicid even temporarily.
--
Thanks.
HATAYAMA, Daisuke
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: hpa@linux.intel.com, ebiederm@xmission.com,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
bp@alien8.de, akpm@linux-foundation.org, fengguang.wu@intel.com,
jingbai.ma@hp.com
Subject: Re: [PATCH v7 1/2] x86, apic: Add disable_cpu_apicid kernel parameter
Date: Thu, 28 Nov 2013 09:18:18 +0900 [thread overview]
Message-ID: <52968BCA.4040803@jp.fujitsu.com> (raw)
In-Reply-To: <20131127151017.GI18706@redhat.com>
(2013/11/28 0:10), Vivek Goyal wrote:
> On Wed, Nov 27, 2013 at 11:00:48AM +0900, HATAYAMA Daisuke wrote:
>> Add disable_cpu_apicid kernel parameter. To use this kernel parameter,
>> specify an initial APIC ID of the corresponding CPU you want to
>> disable.
>>
>> This is mostly used for the kdump 2nd kernel to disable BSP to wake up
>> multiple CPUs without causing system reset or hang due to sending INIT
>> from AP to BSP.
>>
>> Kdump users first figure out initial APIC ID of the BSP, CPU0 in the
>> 1st kernel, for example from /proc/cpuinfo and then set up this kernel
>> parameter for the 2nd kernel using the obtained APIC ID.
>>
>> However, doing this procedure at each boot time manually is awkward,
>> which should be automatically done by user-land service scripts, for
>> example, kexec-tools on fedora/RHEL distributions.
>>
>> This design is more flexible than disabling BSP in kernel boot time
>> automatically in that in kernel boot time we have no choice but
>> referring to ACPI/MP table to obtain initial APIC ID for BSP, meaning
>> that the method is not applicable to the systems without such BIOS
>> tables.
>>
>> One assumption behind this design is that users get initial APIC ID of
>> the BSP in still healthy state and so BSP is uniquely kept in
>> CPU0. Thus, through the kernel parameter, only one initial APIC ID can
>> be specified.
>>
>> boot_cpu_physical_apicid is designed to have the apicid returned by
>> read_apic_id(). However, on some platforms, it is temporarilly
>> modified by the apicid reported as BSP through MP table. This function
>> is called with the modified boot_cpu_physical_apicid.
>>
>> On the platforms, boot_cpu_physical_apicid is always forced to be the
>> apicid of the BSP. Then, disabled_cpu_apicid kernel parameter doesn't
>> work well for apicids for APs.
>>
>> Here we leave improvement of handling boot_cpu_physical_apicid as
>> another work for now since the temporary modification is done on
>> differnet platforms and tests on each platform are required. As a
>> workaround, we directly update boot_cpu_physical_apicid by
>> read_apic_id().
>>
>> Signed-off-by: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
>> ---
>> arch/x86/kernel/apic/apic.c | 49 +++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 49 insertions(+)
>>
>> diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
>> index d278736..a94f618 100644
>> --- a/arch/x86/kernel/apic/apic.c
>> +++ b/arch/x86/kernel/apic/apic.c
>> @@ -75,6 +75,13 @@ unsigned int max_physical_apicid;
>> physid_mask_t phys_cpu_present_map;
>>
>> /*
>> + * Processor to be disabled specified by kernel parameter
>> + * disable_cpu_apicid=<int>, mostly used for the kdump 2nd kernel to
>> + * avoid undefined behaviour caused by sending INIT from AP to BSP.
>> + */
>> +unsigned int disabled_cpu_apicid = BAD_APICID;
>> +
>> +/*
>> * Map cpu index to physical APIC ID
>> */
>> DEFINE_EARLY_PER_CPU_READ_MOSTLY(u16, x86_cpu_to_apicid, BAD_APICID);
>> @@ -2111,9 +2118,42 @@ void disconnect_bsp_APIC(int virt_wire_setup)
>> int generic_processor_info(int apicid, int version)
>> {
>> int cpu, max = nr_cpu_ids;
>> + /*
>> + * boot_cpu_physical_apicid is designed to have the apicid
>> + * returned by read_apic_id(). However, on some platforms, it
>> + * is temporarilly modified by the apicid reported as BSP
>> + * through MP table. Concretely:
>> + *
>> + * - arch/x86/kernel/mpparse.c: MP_processor_info()
>> + * - arch/x86/mm/amdtopology.c: amd_numa_init()
>> + * - arch/x86/platform/visws/visws_quirks.c: MP_processor_info()
>> + *
>> + * This function is executed with the modified
>> + * boot_cpu_physical_apicid. So, disabled_cpu_apicid kernel
>> + * parameter doesn't work.
>> + *
>> + * Since fixing handling of boot_cpu_physical_apicid requires
>> + * another discussion and tests on each platform, we leave it
>> + * for now and here we use read_apic_id() directly by updating
>> + * global scope of boot_cpu_physical_id with the local one.
>> + */
>> + unsigned int boot_cpu_physical_apicid = read_apic_id();
>
> I think this is confusing. Why are you trying to define a local variable
> with same name as global variable. There is no need. I think if we
> simply put the comment there that why are we not making use of
> boot_cpu_physical_apicid, that is good enough and directly read
> the apic id.
>
> if (disabled_cpu_apicid != BAD_APICID &&
> disabled_cpu_apicid != read_apic_id() &&
> disabled_cpu_apicid == apicid) {
>
> }
>
Because there are also other occurrences of boot_cpu_physical_apicid in the
same function, and defining the local variable with the same name needs
one line only, and it's a temporary workaround change, I think it unnatural
to replace boot_cpu_physical_apicid even temporarily.
--
Thanks.
HATAYAMA, Daisuke
next prev parent reply other threads:[~2013-11-28 0:21 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-27 2:00 [PATCH v7 0/3] x86, apic, kexec: Add disable_cpu_apic kernel parameter HATAYAMA Daisuke
2013-11-27 2:00 ` HATAYAMA Daisuke
2013-11-27 2:00 ` [PATCH v7 1/2] x86, apic: Add disable_cpu_apicid " HATAYAMA Daisuke
2013-11-27 2:00 ` HATAYAMA Daisuke
2013-11-27 15:10 ` Vivek Goyal
2013-11-27 15:10 ` Vivek Goyal
2013-11-28 0:18 ` HATAYAMA Daisuke [this message]
2013-11-28 0:18 ` HATAYAMA Daisuke
2013-11-27 2:00 ` [PATCH v7 2/2] Documentation, x86, apic, kexec: " HATAYAMA Daisuke
2013-11-27 2:00 ` HATAYAMA Daisuke
2013-11-27 15:10 ` Vivek Goyal
2013-11-27 15:10 ` Vivek Goyal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52968BCA.4040803@jp.fujitsu.com \
--to=d.hatayama@jp.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=ebiederm@xmission.com \
--cc=fengguang.wu@intel.com \
--cc=hpa@linux.intel.com \
--cc=jingbai.ma@hp.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vgoyal@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.