* [tip:x86/urgent] x86/smpboot: Fix __max_logical_packages estimate
2017-11-14 12:42 ` [PATCH v6 3/3] x86/smpboot: Fix __max_logical_packages estimate Prarit Bhargava
@ 2017-11-17 15:27 ` tip-bot for Prarit Bhargava
2018-02-07 18:44 ` [v6, 3/3] " Simon Gaiser
2018-02-07 18:44 ` [v6,3/3] " Simon Gaiser
2 siblings, 0 replies; 16+ messages in thread
From: tip-bot for Prarit Bhargava @ 2017-11-17 15:27 UTC (permalink / raw)
To: linux-tip-commits
Cc: eranian, tglx, vkuznets, ak, bp, piotr.luc, minipli, borntraeger,
dave.hansen, arvind.yadav.cs, linux-kernel, thomas.lendacky,
peterz, kirill.shutemov, luto, hpa, kan.liang, prarit, mingo,
he.chen, tim.c.chen
Commit-ID: b4c0a7326f5dc0ef7a64128b0ae7d081f4b2cbd1
Gitweb: https://git.kernel.org/tip/b4c0a7326f5dc0ef7a64128b0ae7d081f4b2cbd1
Author: Prarit Bhargava <prarit@redhat.com>
AuthorDate: Tue, 14 Nov 2017 07:42:57 -0500
Committer: Thomas Gleixner <tglx@linutronix.de>
CommitDate: Fri, 17 Nov 2017 16:22:31 +0100
x86/smpboot: Fix __max_logical_packages estimate
A system booted with a small number of cores enabled per package
panics because the estimate of __max_logical_packages is too low.
This occurs when the total number of active cores across all packages is
less than the maximum core count for a single package. e.g.:
On a 4 package system with 20 cores/package where only 4 cores are
enabled on each package, the value of __max_logical_packages is
calculated as DIV_ROUND_UP(16 / 20) = 1 and not 4.
Calculate __max_logical_packages after the cpu enumeration has completed.
Use the boot cpu's data to extrapolate the number of packages.
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Kan Liang <kan.liang@intel.com>
Cc: He Chen <he.chen@linux.intel.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Piotr Luc <piotr.luc@intel.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Arvind Yadav <arvind.yadav.cs@gmail.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Mathias Krause <minipli@googlemail.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Link: https://lkml.kernel.org/r/20171114124257.22013-4-prarit@redhat.com
---
arch/x86/kernel/smpboot.c | 55 +++++++++--------------------------------------
1 file changed, 10 insertions(+), 45 deletions(-)
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index da5e162..3d01df7 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -310,12 +310,6 @@ int topology_update_package_map(unsigned int pkg, unsigned int cpu)
if (new >= 0)
goto found;
- if (logical_packages >= __max_logical_packages) {
- pr_warn("Package %u of CPU %u exceeds BIOS package data %u.\n",
- logical_packages, cpu, __max_logical_packages);
- return -ENOSPC;
- }
-
new = logical_packages++;
if (new != pkg) {
pr_info("CPU %u Converting physical %u to logical package %u\n",
@@ -326,44 +320,6 @@ found:
return 0;
}
-static void __init smp_init_package_map(struct cpuinfo_x86 *c, unsigned int cpu)
-{
- unsigned int ncpus;
-
- /*
- * Today neither Intel nor AMD support heterogenous systems. That
- * might change in the future....
- *
- * While ideally we'd want '* smp_num_siblings' in the below @ncpus
- * computation, this won't actually work since some Intel BIOSes
- * report inconsistent HT data when they disable HT.
- *
- * In particular, they reduce the APIC-IDs to only include the cores,
- * but leave the CPUID topology to say there are (2) siblings.
- * This means we don't know how many threads there will be until
- * after the APIC enumeration.
- *
- * By not including this we'll sometimes over-estimate the number of
- * logical packages by the amount of !present siblings, but this is
- * still better than MAX_LOCAL_APIC.
- *
- * We use total_cpus not nr_cpu_ids because nr_cpu_ids can be limited
- * on the command line leading to a similar issue as the HT disable
- * problem because the hyperthreads are usually enumerated after the
- * primary cores.
- */
- ncpus = boot_cpu_data.x86_max_cores;
- if (!ncpus) {
- pr_warn("x86_max_cores == zero !?!?");
- ncpus = 1;
- }
-
- __max_logical_packages = DIV_ROUND_UP(total_cpus, ncpus);
- pr_info("Max logical packages: %u\n", __max_logical_packages);
-
- topology_update_package_map(c->phys_proc_id, cpu);
-}
-
void __init smp_store_boot_cpu_info(void)
{
int id = 0; /* CPU 0 */
@@ -371,7 +327,7 @@ void __init smp_store_boot_cpu_info(void)
*c = boot_cpu_data;
c->cpu_index = id;
- smp_init_package_map(c, id);
+ topology_update_package_map(c->phys_proc_id, id);
c->initialized = true;
}
@@ -1341,7 +1297,16 @@ void __init native_smp_prepare_boot_cpu(void)
void __init native_smp_cpus_done(unsigned int max_cpus)
{
+ int ncpus;
+
pr_debug("Boot done\n");
+ /*
+ * Today neither Intel nor AMD support heterogenous systems so
+ * extrapolate the boot cpu's data to all packages.
+ */
+ ncpus = cpu_data(0).booted_cores * smp_num_siblings;
+ __max_logical_packages = DIV_ROUND_UP(nr_cpu_ids, ncpus);
+ pr_info("Max logical packages: %u\n", __max_logical_packages);
if (x86_has_numa_in_package)
set_sched_topology(x86_numa_in_package_topology);
^ permalink raw reply related [flat|nested] 16+ messages in thread* Re: [v6, 3/3] x86/smpboot: Fix __max_logical_packages estimate
2017-11-14 12:42 ` [PATCH v6 3/3] x86/smpboot: Fix __max_logical_packages estimate Prarit Bhargava
2017-11-17 15:27 ` [tip:x86/urgent] " tip-bot for Prarit Bhargava
@ 2018-02-07 18:44 ` Simon Gaiser
2018-02-07 18:44 ` [v6,3/3] " Simon Gaiser
2 siblings, 0 replies; 16+ messages in thread
From: Simon Gaiser @ 2018-02-07 18:44 UTC (permalink / raw)
To: Prarit Bhargava, xen-devel
Cc: Tom Lendacky, Vitaly Kuznetsov, Andi Kleen, Christian Borntraeger,
Peter Zijlstra, Kan Liang, x86, linux-kernel, Stephane Eranian,
He Chen, Dave Hansen, Piotr Luc, Ingo Molnar, Andy Lutomirski,
H. Peter Anvin, Arvind Yadav, Thomas Gleixner, Borislav Petkov,
Tim Chen, Mathias Krause, Kirill A. Shutemov
[-- Attachment #1.1.1: Type: text/plain, Size: 5203 bytes --]
Prarit Bhargava:
> A system booted with a small number of cores enabled per package
> panics because the estimate of __max_logical_packages is too low.
> This occurs when the total number of active cores across all packages
> is less than the maximum core count for a single package.
>
> ie) On a 4 package system with 20 cores/package where only 4 cores
> are enabled on each package, the value of __max_logical_packages is
> calculated as DIV_ROUND_UP(16 / 20) = 1 and not 4.
>
> Calculate __max_logical_packages after the cpu enumeration has completed.
> Use the boot cpu's data to extrapolate the number of packages.
>
> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: x86@kernel.org
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Andi Kleen <ak@linux.intel.com>
> Cc: Dave Hansen <dave.hansen@intel.com>
> Cc: Piotr Luc <piotr.luc@intel.com>
> Cc: Kan Liang <kan.liang@intel.com>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: Stephane Eranian <eranian@google.com>
> Cc: Prarit Bhargava <prarit@redhat.com>
> Cc: Arvind Yadav <arvind.yadav.cs@gmail.com>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Christian Borntraeger <borntraeger@de.ibm.com>
> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
> Cc: Tom Lendacky <thomas.lendacky@amd.com>
> Cc: He Chen <he.chen@linux.intel.com>
> Cc: Mathias Krause <minipli@googlemail.com>
> Cc: Tim Chen <tim.c.chen@linux.intel.com>
> Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
> ---
> arch/x86/kernel/smpboot.c | 55 +++++++++--------------------------------------
> 1 file changed, 10 insertions(+), 45 deletions(-)
>
> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
> index 838d36ff7ba6..2e3c5a394e79 100644
> --- a/arch/x86/kernel/smpboot.c
> +++ b/arch/x86/kernel/smpboot.c
> @@ -308,12 +308,6 @@ int topology_update_package_map(unsigned int pkg, unsigned int cpu)
> if (new >= 0)
> goto found;
>
> - if (logical_packages >= __max_logical_packages) {
> - pr_warn("Package %u of CPU %u exceeds BIOS package data %u.\n",
> - logical_packages, cpu, __max_logical_packages);
> - return -ENOSPC;
> - }
> -
> new = logical_packages++;
> if (new != pkg)
> pr_info("CPU %u Converting physical %u to logical package %u\n",
> @@ -323,44 +317,6 @@ int topology_update_package_map(unsigned int pkg, unsigned int cpu)
> return 0;
> }
>
> -static void __init smp_init_package_map(struct cpuinfo_x86 *c, unsigned int cpu)
> -{
> - unsigned int ncpus;
> -
> - /*
> - * Today neither Intel nor AMD support heterogenous systems. That
> - * might change in the future....
> - *
> - * While ideally we'd want '* smp_num_siblings' in the below @ncpus
> - * computation, this won't actually work since some Intel BIOSes
> - * report inconsistent HT data when they disable HT.
> - *
> - * In particular, they reduce the APIC-IDs to only include the cores,
> - * but leave the CPUID topology to say there are (2) siblings.
> - * This means we don't know how many threads there will be until
> - * after the APIC enumeration.
> - *
> - * By not including this we'll sometimes over-estimate the number of
> - * logical packages by the amount of !present siblings, but this is
> - * still better than MAX_LOCAL_APIC.
> - *
> - * We use total_cpus not nr_cpu_ids because nr_cpu_ids can be limited
> - * on the command line leading to a similar issue as the HT disable
> - * problem because the hyperthreads are usually enumerated after the
> - * primary cores.
> - */
> - ncpus = boot_cpu_data.x86_max_cores;
> - if (!ncpus) {
> - pr_warn("x86_max_cores == zero !?!?");
> - ncpus = 1;
> - }
> -
> - __max_logical_packages = DIV_ROUND_UP(total_cpus, ncpus);
> - pr_info("Max logical packages: %u\n", __max_logical_packages);
> -
> - topology_update_package_map(c->phys_proc_id, cpu);
> -}
> -
> void __init smp_store_boot_cpu_info(void)
> {
> int id = 0; /* CPU 0 */
> @@ -368,7 +324,7 @@ void __init smp_store_boot_cpu_info(void)
>
> *c = boot_cpu_data;
> c->cpu_index = id;
> - smp_init_package_map(c, id);
> + topology_update_package_map(c->phys_proc_id, id);
> cpu_data(id).set = 1;
> }
>
> @@ -1371,7 +1327,16 @@ void __init native_smp_prepare_boot_cpu(void)
>
> void __init native_smp_cpus_done(unsigned int max_cpus)
> {
> + int ncpus;
> +
> pr_debug("Boot done\n");
> + /*
> + * Today neither Intel nor AMD support heterogenous systems so
> + * extrapolate the boot cpu's data to all packages.
> + */
> + ncpus = cpu_data(0).booted_cores * smp_num_siblings;
> + __max_logical_packages = DIV_ROUND_UP(nr_cpu_ids, ncpus);
> + pr_info("Max logical packages: %u\n", __max_logical_packages);
>
> if (x86_has_numa_in_package)
> set_sched_topology(x86_numa_in_package_topology);
This breaks booting as Xen PV domain for me. The problem seems to be
that native_smp_cpus_done() is never called on a PV domain. So
__max_logical_packages is uninitialized and this leads to a NULL
pointer dereference in coretemp.
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [v6,3/3] x86/smpboot: Fix __max_logical_packages estimate
2017-11-14 12:42 ` [PATCH v6 3/3] x86/smpboot: Fix __max_logical_packages estimate Prarit Bhargava
2017-11-17 15:27 ` [tip:x86/urgent] " tip-bot for Prarit Bhargava
2018-02-07 18:44 ` [v6, 3/3] " Simon Gaiser
@ 2018-02-07 18:44 ` Simon Gaiser
2018-02-07 19:04 ` Prarit Bhargava
2018-02-07 19:04 ` Prarit Bhargava
2 siblings, 2 replies; 16+ messages in thread
From: Simon Gaiser @ 2018-02-07 18:44 UTC (permalink / raw)
To: Prarit Bhargava, xen-devel
Cc: linux-kernel, Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86,
Peter Zijlstra, Andi Kleen, Dave Hansen, Piotr Luc, Kan Liang,
Borislav Petkov, Stephane Eranian, Arvind Yadav, Andy Lutomirski,
Christian Borntraeger, Kirill A. Shutemov, Tom Lendacky, He Chen,
Mathias Krause, Tim Chen, Vitaly Kuznetsov
[-- Attachment #1.1: Type: text/plain, Size: 5203 bytes --]
Prarit Bhargava:
> A system booted with a small number of cores enabled per package
> panics because the estimate of __max_logical_packages is too low.
> This occurs when the total number of active cores across all packages
> is less than the maximum core count for a single package.
>
> ie) On a 4 package system with 20 cores/package where only 4 cores
> are enabled on each package, the value of __max_logical_packages is
> calculated as DIV_ROUND_UP(16 / 20) = 1 and not 4.
>
> Calculate __max_logical_packages after the cpu enumeration has completed.
> Use the boot cpu's data to extrapolate the number of packages.
>
> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: x86@kernel.org
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Andi Kleen <ak@linux.intel.com>
> Cc: Dave Hansen <dave.hansen@intel.com>
> Cc: Piotr Luc <piotr.luc@intel.com>
> Cc: Kan Liang <kan.liang@intel.com>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: Stephane Eranian <eranian@google.com>
> Cc: Prarit Bhargava <prarit@redhat.com>
> Cc: Arvind Yadav <arvind.yadav.cs@gmail.com>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Christian Borntraeger <borntraeger@de.ibm.com>
> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
> Cc: Tom Lendacky <thomas.lendacky@amd.com>
> Cc: He Chen <he.chen@linux.intel.com>
> Cc: Mathias Krause <minipli@googlemail.com>
> Cc: Tim Chen <tim.c.chen@linux.intel.com>
> Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
> ---
> arch/x86/kernel/smpboot.c | 55 +++++++++--------------------------------------
> 1 file changed, 10 insertions(+), 45 deletions(-)
>
> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
> index 838d36ff7ba6..2e3c5a394e79 100644
> --- a/arch/x86/kernel/smpboot.c
> +++ b/arch/x86/kernel/smpboot.c
> @@ -308,12 +308,6 @@ int topology_update_package_map(unsigned int pkg, unsigned int cpu)
> if (new >= 0)
> goto found;
>
> - if (logical_packages >= __max_logical_packages) {
> - pr_warn("Package %u of CPU %u exceeds BIOS package data %u.\n",
> - logical_packages, cpu, __max_logical_packages);
> - return -ENOSPC;
> - }
> -
> new = logical_packages++;
> if (new != pkg)
> pr_info("CPU %u Converting physical %u to logical package %u\n",
> @@ -323,44 +317,6 @@ int topology_update_package_map(unsigned int pkg, unsigned int cpu)
> return 0;
> }
>
> -static void __init smp_init_package_map(struct cpuinfo_x86 *c, unsigned int cpu)
> -{
> - unsigned int ncpus;
> -
> - /*
> - * Today neither Intel nor AMD support heterogenous systems. That
> - * might change in the future....
> - *
> - * While ideally we'd want '* smp_num_siblings' in the below @ncpus
> - * computation, this won't actually work since some Intel BIOSes
> - * report inconsistent HT data when they disable HT.
> - *
> - * In particular, they reduce the APIC-IDs to only include the cores,
> - * but leave the CPUID topology to say there are (2) siblings.
> - * This means we don't know how many threads there will be until
> - * after the APIC enumeration.
> - *
> - * By not including this we'll sometimes over-estimate the number of
> - * logical packages by the amount of !present siblings, but this is
> - * still better than MAX_LOCAL_APIC.
> - *
> - * We use total_cpus not nr_cpu_ids because nr_cpu_ids can be limited
> - * on the command line leading to a similar issue as the HT disable
> - * problem because the hyperthreads are usually enumerated after the
> - * primary cores.
> - */
> - ncpus = boot_cpu_data.x86_max_cores;
> - if (!ncpus) {
> - pr_warn("x86_max_cores == zero !?!?");
> - ncpus = 1;
> - }
> -
> - __max_logical_packages = DIV_ROUND_UP(total_cpus, ncpus);
> - pr_info("Max logical packages: %u\n", __max_logical_packages);
> -
> - topology_update_package_map(c->phys_proc_id, cpu);
> -}
> -
> void __init smp_store_boot_cpu_info(void)
> {
> int id = 0; /* CPU 0 */
> @@ -368,7 +324,7 @@ void __init smp_store_boot_cpu_info(void)
>
> *c = boot_cpu_data;
> c->cpu_index = id;
> - smp_init_package_map(c, id);
> + topology_update_package_map(c->phys_proc_id, id);
> cpu_data(id).set = 1;
> }
>
> @@ -1371,7 +1327,16 @@ void __init native_smp_prepare_boot_cpu(void)
>
> void __init native_smp_cpus_done(unsigned int max_cpus)
> {
> + int ncpus;
> +
> pr_debug("Boot done\n");
> + /*
> + * Today neither Intel nor AMD support heterogenous systems so
> + * extrapolate the boot cpu's data to all packages.
> + */
> + ncpus = cpu_data(0).booted_cores * smp_num_siblings;
> + __max_logical_packages = DIV_ROUND_UP(nr_cpu_ids, ncpus);
> + pr_info("Max logical packages: %u\n", __max_logical_packages);
>
> if (x86_has_numa_in_package)
> set_sched_topology(x86_numa_in_package_topology);
This breaks booting as Xen PV domain for me. The problem seems to be
that native_smp_cpus_done() is never called on a PV domain. So
__max_logical_packages is uninitialized and this leads to a NULL
pointer dereference in coretemp.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [v6,3/3] x86/smpboot: Fix __max_logical_packages estimate
2018-02-07 18:44 ` [v6,3/3] " Simon Gaiser
@ 2018-02-07 19:04 ` Prarit Bhargava
2018-02-07 19:26 ` Simon Gaiser
2018-02-07 19:26 ` Simon Gaiser
2018-02-07 19:04 ` Prarit Bhargava
1 sibling, 2 replies; 16+ messages in thread
From: Prarit Bhargava @ 2018-02-07 19:04 UTC (permalink / raw)
To: Simon Gaiser, xen-devel
Cc: linux-kernel, Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86,
Peter Zijlstra, Andi Kleen, Dave Hansen, Piotr Luc, Kan Liang,
Borislav Petkov, Stephane Eranian, Arvind Yadav, Andy Lutomirski,
Christian Borntraeger, Kirill A. Shutemov, Tom Lendacky, He Chen,
Mathias Krause, Tim Chen, Vitaly Kuznetsov
On 02/07/2018 01:44 PM, Simon Gaiser wrote:
> Prarit Bhargava:
>> A system booted with a small number of cores enabled per package
>> panics because the estimate of __max_logical_packages is too low.
>> This occurs when the total number of active cores across all packages
>> is less than the maximum core count for a single package.
>>
>> ie) On a 4 package system with 20 cores/package where only 4 cores
>> are enabled on each package, the value of __max_logical_packages is
>> calculated as DIV_ROUND_UP(16 / 20) = 1 and not 4.
>>
>> Calculate __max_logical_packages after the cpu enumeration has completed.
>> Use the boot cpu's data to extrapolate the number of packages.
>>
>> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Ingo Molnar <mingo@redhat.com>
>> Cc: "H. Peter Anvin" <hpa@zytor.com>
>> Cc: x86@kernel.org
>> Cc: Peter Zijlstra <peterz@infradead.org>
>> Cc: Andi Kleen <ak@linux.intel.com>
>> Cc: Dave Hansen <dave.hansen@intel.com>
>> Cc: Piotr Luc <piotr.luc@intel.com>
>> Cc: Kan Liang <kan.liang@intel.com>
>> Cc: Borislav Petkov <bp@suse.de>
>> Cc: Stephane Eranian <eranian@google.com>
>> Cc: Prarit Bhargava <prarit@redhat.com>
>> Cc: Arvind Yadav <arvind.yadav.cs@gmail.com>
>> Cc: Andy Lutomirski <luto@kernel.org>
>> Cc: Christian Borntraeger <borntraeger@de.ibm.com>
>> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
>> Cc: Tom Lendacky <thomas.lendacky@amd.com>
>> Cc: He Chen <he.chen@linux.intel.com>
>> Cc: Mathias Krause <minipli@googlemail.com>
>> Cc: Tim Chen <tim.c.chen@linux.intel.com>
>> Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
>> ---
>> arch/x86/kernel/smpboot.c | 55 +++++++++--------------------------------------
>> 1 file changed, 10 insertions(+), 45 deletions(-)
>>
>> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
>> index 838d36ff7ba6..2e3c5a394e79 100644
>> --- a/arch/x86/kernel/smpboot.c
>> +++ b/arch/x86/kernel/smpboot.c
>> @@ -308,12 +308,6 @@ int topology_update_package_map(unsigned int pkg, unsigned int cpu)
>> if (new >= 0)
>> goto found;
>>
>> - if (logical_packages >= __max_logical_packages) {
>> - pr_warn("Package %u of CPU %u exceeds BIOS package data %u.\n",
>> - logical_packages, cpu, __max_logical_packages);
>> - return -ENOSPC;
>> - }
>> -
>> new = logical_packages++;
>> if (new != pkg)
>> pr_info("CPU %u Converting physical %u to logical package %u\n",
>> @@ -323,44 +317,6 @@ int topology_update_package_map(unsigned int pkg, unsigned int cpu)
>> return 0;
>> }
>>
>> -static void __init smp_init_package_map(struct cpuinfo_x86 *c, unsigned int cpu)
>> -{
>> - unsigned int ncpus;
>> -
>> - /*
>> - * Today neither Intel nor AMD support heterogenous systems. That
>> - * might change in the future....
>> - *
>> - * While ideally we'd want '* smp_num_siblings' in the below @ncpus
>> - * computation, this won't actually work since some Intel BIOSes
>> - * report inconsistent HT data when they disable HT.
>> - *
>> - * In particular, they reduce the APIC-IDs to only include the cores,
>> - * but leave the CPUID topology to say there are (2) siblings.
>> - * This means we don't know how many threads there will be until
>> - * after the APIC enumeration.
>> - *
>> - * By not including this we'll sometimes over-estimate the number of
>> - * logical packages by the amount of !present siblings, but this is
>> - * still better than MAX_LOCAL_APIC.
>> - *
>> - * We use total_cpus not nr_cpu_ids because nr_cpu_ids can be limited
>> - * on the command line leading to a similar issue as the HT disable
>> - * problem because the hyperthreads are usually enumerated after the
>> - * primary cores.
>> - */
>> - ncpus = boot_cpu_data.x86_max_cores;
>> - if (!ncpus) {
>> - pr_warn("x86_max_cores == zero !?!?");
>> - ncpus = 1;
>> - }
>> -
>> - __max_logical_packages = DIV_ROUND_UP(total_cpus, ncpus);
>> - pr_info("Max logical packages: %u\n", __max_logical_packages);
>> -
>> - topology_update_package_map(c->phys_proc_id, cpu);
>> -}
>> -
>> void __init smp_store_boot_cpu_info(void)
>> {
>> int id = 0; /* CPU 0 */
>> @@ -368,7 +324,7 @@ void __init smp_store_boot_cpu_info(void)
>>
>> *c = boot_cpu_data;
>> c->cpu_index = id;
>> - smp_init_package_map(c, id);
>> + topology_update_package_map(c->phys_proc_id, id);
>> cpu_data(id).set = 1;
>> }
>>
>> @@ -1371,7 +1327,16 @@ void __init native_smp_prepare_boot_cpu(void)
>>
>> void __init native_smp_cpus_done(unsigned int max_cpus)
>> {
>> + int ncpus;
>> +
>> pr_debug("Boot done\n");
>> + /*
>> + * Today neither Intel nor AMD support heterogenous systems so
>> + * extrapolate the boot cpu's data to all packages.
>> + */
>> + ncpus = cpu_data(0).booted_cores * smp_num_siblings;
>> + __max_logical_packages = DIV_ROUND_UP(nr_cpu_ids, ncpus);
>> + pr_info("Max logical packages: %u\n", __max_logical_packages);
>>
>> if (x86_has_numa_in_package)
>> set_sched_topology(x86_numa_in_package_topology);
>
> This breaks booting as Xen PV domain for me. The problem seems to be
> that native_smp_cpus_done() is never called on a PV domain. So
> __max_logical_packages is uninitialized and this leads to a NULL
> pointer dereference in coretemp.
>
I'll see if I can figure out a way to test that. Does 947134d9b00f
("x86/smpboot: Do not use smp_num_siblings in __max_logical_packages
calculation") help?
P.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [v6,3/3] x86/smpboot: Fix __max_logical_packages estimate
2018-02-07 19:04 ` Prarit Bhargava
@ 2018-02-07 19:26 ` Simon Gaiser
2018-02-07 19:31 ` Prarit Bhargava
2018-02-07 19:31 ` [v6, 3/3] " Prarit Bhargava
2018-02-07 19:26 ` Simon Gaiser
1 sibling, 2 replies; 16+ messages in thread
From: Simon Gaiser @ 2018-02-07 19:26 UTC (permalink / raw)
To: Prarit Bhargava, xen-devel
Cc: linux-kernel, Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86,
Peter Zijlstra, Andi Kleen, Dave Hansen, Piotr Luc, Kan Liang,
Borislav Petkov, Stephane Eranian, Arvind Yadav, Andy Lutomirski,
Christian Borntraeger, Kirill A. Shutemov, Tom Lendacky, He Chen,
Mathias Krause, Tim Chen, Vitaly Kuznetsov
[-- Attachment #1.1: Type: text/plain, Size: 5797 bytes --]
Prarit Bhargava:
> On 02/07/2018 01:44 PM, Simon Gaiser wrote:
>> Prarit Bhargava:
>>> A system booted with a small number of cores enabled per package
>>> panics because the estimate of __max_logical_packages is too low.
>>> This occurs when the total number of active cores across all packages
>>> is less than the maximum core count for a single package.
>>>
>>> ie) On a 4 package system with 20 cores/package where only 4 cores
>>> are enabled on each package, the value of __max_logical_packages is
>>> calculated as DIV_ROUND_UP(16 / 20) = 1 and not 4.
>>>
>>> Calculate __max_logical_packages after the cpu enumeration has completed.
>>> Use the boot cpu's data to extrapolate the number of packages.
>>>
>>> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
>>> Cc: Thomas Gleixner <tglx@linutronix.de>
>>> Cc: Ingo Molnar <mingo@redhat.com>
>>> Cc: "H. Peter Anvin" <hpa@zytor.com>
>>> Cc: x86@kernel.org
>>> Cc: Peter Zijlstra <peterz@infradead.org>
>>> Cc: Andi Kleen <ak@linux.intel.com>
>>> Cc: Dave Hansen <dave.hansen@intel.com>
>>> Cc: Piotr Luc <piotr.luc@intel.com>
>>> Cc: Kan Liang <kan.liang@intel.com>
>>> Cc: Borislav Petkov <bp@suse.de>
>>> Cc: Stephane Eranian <eranian@google.com>
>>> Cc: Prarit Bhargava <prarit@redhat.com>
>>> Cc: Arvind Yadav <arvind.yadav.cs@gmail.com>
>>> Cc: Andy Lutomirski <luto@kernel.org>
>>> Cc: Christian Borntraeger <borntraeger@de.ibm.com>
>>> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
>>> Cc: Tom Lendacky <thomas.lendacky@amd.com>
>>> Cc: He Chen <he.chen@linux.intel.com>
>>> Cc: Mathias Krause <minipli@googlemail.com>
>>> Cc: Tim Chen <tim.c.chen@linux.intel.com>
>>> Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
>>> ---
>>> arch/x86/kernel/smpboot.c | 55 +++++++++--------------------------------------
>>> 1 file changed, 10 insertions(+), 45 deletions(-)
>>>
>>> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
>>> index 838d36ff7ba6..2e3c5a394e79 100644
>>> --- a/arch/x86/kernel/smpboot.c
>>> +++ b/arch/x86/kernel/smpboot.c
>>> @@ -308,12 +308,6 @@ int topology_update_package_map(unsigned int pkg, unsigned int cpu)
>>> if (new >= 0)
>>> goto found;
>>>
>>> - if (logical_packages >= __max_logical_packages) {
>>> - pr_warn("Package %u of CPU %u exceeds BIOS package data %u.\n",
>>> - logical_packages, cpu, __max_logical_packages);
>>> - return -ENOSPC;
>>> - }
>>> -
>>> new = logical_packages++;
>>> if (new != pkg)
>>> pr_info("CPU %u Converting physical %u to logical package %u\n",
>>> @@ -323,44 +317,6 @@ int topology_update_package_map(unsigned int pkg, unsigned int cpu)
>>> return 0;
>>> }
>>>
>>> -static void __init smp_init_package_map(struct cpuinfo_x86 *c, unsigned int cpu)
>>> -{
>>> - unsigned int ncpus;
>>> -
>>> - /*
>>> - * Today neither Intel nor AMD support heterogenous systems. That
>>> - * might change in the future....
>>> - *
>>> - * While ideally we'd want '* smp_num_siblings' in the below @ncpus
>>> - * computation, this won't actually work since some Intel BIOSes
>>> - * report inconsistent HT data when they disable HT.
>>> - *
>>> - * In particular, they reduce the APIC-IDs to only include the cores,
>>> - * but leave the CPUID topology to say there are (2) siblings.
>>> - * This means we don't know how many threads there will be until
>>> - * after the APIC enumeration.
>>> - *
>>> - * By not including this we'll sometimes over-estimate the number of
>>> - * logical packages by the amount of !present siblings, but this is
>>> - * still better than MAX_LOCAL_APIC.
>>> - *
>>> - * We use total_cpus not nr_cpu_ids because nr_cpu_ids can be limited
>>> - * on the command line leading to a similar issue as the HT disable
>>> - * problem because the hyperthreads are usually enumerated after the
>>> - * primary cores.
>>> - */
>>> - ncpus = boot_cpu_data.x86_max_cores;
>>> - if (!ncpus) {
>>> - pr_warn("x86_max_cores == zero !?!?");
>>> - ncpus = 1;
>>> - }
>>> -
>>> - __max_logical_packages = DIV_ROUND_UP(total_cpus, ncpus);
>>> - pr_info("Max logical packages: %u\n", __max_logical_packages);
>>> -
>>> - topology_update_package_map(c->phys_proc_id, cpu);
>>> -}
>>> -
>>> void __init smp_store_boot_cpu_info(void)
>>> {
>>> int id = 0; /* CPU 0 */
>>> @@ -368,7 +324,7 @@ void __init smp_store_boot_cpu_info(void)
>>>
>>> *c = boot_cpu_data;
>>> c->cpu_index = id;
>>> - smp_init_package_map(c, id);
>>> + topology_update_package_map(c->phys_proc_id, id);
>>> cpu_data(id).set = 1;
>>> }
>>>
>>> @@ -1371,7 +1327,16 @@ void __init native_smp_prepare_boot_cpu(void)
>>>
>>> void __init native_smp_cpus_done(unsigned int max_cpus)
>>> {
>>> + int ncpus;
>>> +
>>> pr_debug("Boot done\n");
>>> + /*
>>> + * Today neither Intel nor AMD support heterogenous systems so
>>> + * extrapolate the boot cpu's data to all packages.
>>> + */
>>> + ncpus = cpu_data(0).booted_cores * smp_num_siblings;
>>> + __max_logical_packages = DIV_ROUND_UP(nr_cpu_ids, ncpus);
>>> + pr_info("Max logical packages: %u\n", __max_logical_packages);
>>>
>>> if (x86_has_numa_in_package)
>>> set_sched_topology(x86_numa_in_package_topology);
>>
>> This breaks booting as Xen PV domain for me. The problem seems to be
>> that native_smp_cpus_done() is never called on a PV domain. So
>> __max_logical_packages is uninitialized and this leads to a NULL
>> pointer dereference in coretemp.
>>
>
> I'll see if I can figure out a way to test that.
Ok, thanks. If you need some logs, or if I should test something just
ask.
> Does 947134d9b00f
> ("x86/smpboot: Do not use smp_num_siblings in __max_logical_packages
> calculation") help?
No.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [v6,3/3] x86/smpboot: Fix __max_logical_packages estimate
2018-02-07 19:26 ` Simon Gaiser
@ 2018-02-07 19:31 ` Prarit Bhargava
2018-02-07 19:31 ` [v6, 3/3] " Prarit Bhargava
1 sibling, 0 replies; 16+ messages in thread
From: Prarit Bhargava @ 2018-02-07 19:31 UTC (permalink / raw)
To: Simon Gaiser, xen-devel
Cc: linux-kernel, Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86,
Peter Zijlstra, Andi Kleen, Dave Hansen, Piotr Luc, Kan Liang,
Borislav Petkov, Stephane Eranian, Arvind Yadav, Andy Lutomirski,
Christian Borntraeger, Kirill A. Shutemov, Tom Lendacky, He Chen,
Mathias Krause, Tim Chen, Vitaly Kuznetsov
On 02/07/2018 02:26 PM, Simon Gaiser wrote:
> Prarit Bhargava:
>> On 02/07/2018 01:44 PM, Simon Gaiser wrote:
<snip>
>>> This breaks booting as Xen PV domain for me. The problem seems to be
>>> that native_smp_cpus_done() is never called on a PV domain. So
>>> __max_logical_packages is uninitialized and this leads to a NULL
>>> pointer dereference in coretemp.
>>>
>>
>> I'll see if I can figure out a way to test that.
>
> Ok, thanks. If you need some logs, or if I should test something just
> ask.
>
Thanks, I may send you a patch off-list to test.
>> Does 947134d9b00f
>> ("x86/smpboot: Do not use smp_num_siblings in __max_logical_packages
>> calculation") help?
>
> No.
>
Yeah, your description was absolutely correct. native_smp_cpus_done() is only
called for HVM guests and not PV. I'm going to think about that and send you a
patch in a bit.
P.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [v6, 3/3] x86/smpboot: Fix __max_logical_packages estimate
2018-02-07 19:26 ` Simon Gaiser
2018-02-07 19:31 ` Prarit Bhargava
@ 2018-02-07 19:31 ` Prarit Bhargava
1 sibling, 0 replies; 16+ messages in thread
From: Prarit Bhargava @ 2018-02-07 19:31 UTC (permalink / raw)
To: Simon Gaiser, xen-devel
Cc: Tom Lendacky, Vitaly Kuznetsov, Andi Kleen, Christian Borntraeger,
Peter Zijlstra, Kan Liang, x86, linux-kernel, Stephane Eranian,
He Chen, Dave Hansen, Piotr Luc, Ingo Molnar, Andy Lutomirski,
H. Peter Anvin, Arvind Yadav, Thomas Gleixner, Borislav Petkov,
Tim Chen, Mathias Krause, Kirill A. Shutemov
On 02/07/2018 02:26 PM, Simon Gaiser wrote:
> Prarit Bhargava:
>> On 02/07/2018 01:44 PM, Simon Gaiser wrote:
<snip>
>>> This breaks booting as Xen PV domain for me. The problem seems to be
>>> that native_smp_cpus_done() is never called on a PV domain. So
>>> __max_logical_packages is uninitialized and this leads to a NULL
>>> pointer dereference in coretemp.
>>>
>>
>> I'll see if I can figure out a way to test that.
>
> Ok, thanks. If you need some logs, or if I should test something just
> ask.
>
Thanks, I may send you a patch off-list to test.
>> Does 947134d9b00f
>> ("x86/smpboot: Do not use smp_num_siblings in __max_logical_packages
>> calculation") help?
>
> No.
>
Yeah, your description was absolutely correct. native_smp_cpus_done() is only
called for HVM guests and not PV. I'm going to think about that and send you a
patch in a bit.
P.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [v6, 3/3] x86/smpboot: Fix __max_logical_packages estimate
2018-02-07 19:04 ` Prarit Bhargava
2018-02-07 19:26 ` Simon Gaiser
@ 2018-02-07 19:26 ` Simon Gaiser
1 sibling, 0 replies; 16+ messages in thread
From: Simon Gaiser @ 2018-02-07 19:26 UTC (permalink / raw)
To: Prarit Bhargava, xen-devel
Cc: Tom Lendacky, Vitaly Kuznetsov, Andi Kleen, Christian Borntraeger,
Peter Zijlstra, Kan Liang, x86, linux-kernel, Stephane Eranian,
He Chen, Dave Hansen, Piotr Luc, Ingo Molnar, Andy Lutomirski,
H. Peter Anvin, Arvind Yadav, Thomas Gleixner, Borislav Petkov,
Tim Chen, Mathias Krause, Kirill A. Shutemov
[-- Attachment #1.1.1: Type: text/plain, Size: 5797 bytes --]
Prarit Bhargava:
> On 02/07/2018 01:44 PM, Simon Gaiser wrote:
>> Prarit Bhargava:
>>> A system booted with a small number of cores enabled per package
>>> panics because the estimate of __max_logical_packages is too low.
>>> This occurs when the total number of active cores across all packages
>>> is less than the maximum core count for a single package.
>>>
>>> ie) On a 4 package system with 20 cores/package where only 4 cores
>>> are enabled on each package, the value of __max_logical_packages is
>>> calculated as DIV_ROUND_UP(16 / 20) = 1 and not 4.
>>>
>>> Calculate __max_logical_packages after the cpu enumeration has completed.
>>> Use the boot cpu's data to extrapolate the number of packages.
>>>
>>> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
>>> Cc: Thomas Gleixner <tglx@linutronix.de>
>>> Cc: Ingo Molnar <mingo@redhat.com>
>>> Cc: "H. Peter Anvin" <hpa@zytor.com>
>>> Cc: x86@kernel.org
>>> Cc: Peter Zijlstra <peterz@infradead.org>
>>> Cc: Andi Kleen <ak@linux.intel.com>
>>> Cc: Dave Hansen <dave.hansen@intel.com>
>>> Cc: Piotr Luc <piotr.luc@intel.com>
>>> Cc: Kan Liang <kan.liang@intel.com>
>>> Cc: Borislav Petkov <bp@suse.de>
>>> Cc: Stephane Eranian <eranian@google.com>
>>> Cc: Prarit Bhargava <prarit@redhat.com>
>>> Cc: Arvind Yadav <arvind.yadav.cs@gmail.com>
>>> Cc: Andy Lutomirski <luto@kernel.org>
>>> Cc: Christian Borntraeger <borntraeger@de.ibm.com>
>>> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
>>> Cc: Tom Lendacky <thomas.lendacky@amd.com>
>>> Cc: He Chen <he.chen@linux.intel.com>
>>> Cc: Mathias Krause <minipli@googlemail.com>
>>> Cc: Tim Chen <tim.c.chen@linux.intel.com>
>>> Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
>>> ---
>>> arch/x86/kernel/smpboot.c | 55 +++++++++--------------------------------------
>>> 1 file changed, 10 insertions(+), 45 deletions(-)
>>>
>>> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
>>> index 838d36ff7ba6..2e3c5a394e79 100644
>>> --- a/arch/x86/kernel/smpboot.c
>>> +++ b/arch/x86/kernel/smpboot.c
>>> @@ -308,12 +308,6 @@ int topology_update_package_map(unsigned int pkg, unsigned int cpu)
>>> if (new >= 0)
>>> goto found;
>>>
>>> - if (logical_packages >= __max_logical_packages) {
>>> - pr_warn("Package %u of CPU %u exceeds BIOS package data %u.\n",
>>> - logical_packages, cpu, __max_logical_packages);
>>> - return -ENOSPC;
>>> - }
>>> -
>>> new = logical_packages++;
>>> if (new != pkg)
>>> pr_info("CPU %u Converting physical %u to logical package %u\n",
>>> @@ -323,44 +317,6 @@ int topology_update_package_map(unsigned int pkg, unsigned int cpu)
>>> return 0;
>>> }
>>>
>>> -static void __init smp_init_package_map(struct cpuinfo_x86 *c, unsigned int cpu)
>>> -{
>>> - unsigned int ncpus;
>>> -
>>> - /*
>>> - * Today neither Intel nor AMD support heterogenous systems. That
>>> - * might change in the future....
>>> - *
>>> - * While ideally we'd want '* smp_num_siblings' in the below @ncpus
>>> - * computation, this won't actually work since some Intel BIOSes
>>> - * report inconsistent HT data when they disable HT.
>>> - *
>>> - * In particular, they reduce the APIC-IDs to only include the cores,
>>> - * but leave the CPUID topology to say there are (2) siblings.
>>> - * This means we don't know how many threads there will be until
>>> - * after the APIC enumeration.
>>> - *
>>> - * By not including this we'll sometimes over-estimate the number of
>>> - * logical packages by the amount of !present siblings, but this is
>>> - * still better than MAX_LOCAL_APIC.
>>> - *
>>> - * We use total_cpus not nr_cpu_ids because nr_cpu_ids can be limited
>>> - * on the command line leading to a similar issue as the HT disable
>>> - * problem because the hyperthreads are usually enumerated after the
>>> - * primary cores.
>>> - */
>>> - ncpus = boot_cpu_data.x86_max_cores;
>>> - if (!ncpus) {
>>> - pr_warn("x86_max_cores == zero !?!?");
>>> - ncpus = 1;
>>> - }
>>> -
>>> - __max_logical_packages = DIV_ROUND_UP(total_cpus, ncpus);
>>> - pr_info("Max logical packages: %u\n", __max_logical_packages);
>>> -
>>> - topology_update_package_map(c->phys_proc_id, cpu);
>>> -}
>>> -
>>> void __init smp_store_boot_cpu_info(void)
>>> {
>>> int id = 0; /* CPU 0 */
>>> @@ -368,7 +324,7 @@ void __init smp_store_boot_cpu_info(void)
>>>
>>> *c = boot_cpu_data;
>>> c->cpu_index = id;
>>> - smp_init_package_map(c, id);
>>> + topology_update_package_map(c->phys_proc_id, id);
>>> cpu_data(id).set = 1;
>>> }
>>>
>>> @@ -1371,7 +1327,16 @@ void __init native_smp_prepare_boot_cpu(void)
>>>
>>> void __init native_smp_cpus_done(unsigned int max_cpus)
>>> {
>>> + int ncpus;
>>> +
>>> pr_debug("Boot done\n");
>>> + /*
>>> + * Today neither Intel nor AMD support heterogenous systems so
>>> + * extrapolate the boot cpu's data to all packages.
>>> + */
>>> + ncpus = cpu_data(0).booted_cores * smp_num_siblings;
>>> + __max_logical_packages = DIV_ROUND_UP(nr_cpu_ids, ncpus);
>>> + pr_info("Max logical packages: %u\n", __max_logical_packages);
>>>
>>> if (x86_has_numa_in_package)
>>> set_sched_topology(x86_numa_in_package_topology);
>>
>> This breaks booting as Xen PV domain for me. The problem seems to be
>> that native_smp_cpus_done() is never called on a PV domain. So
>> __max_logical_packages is uninitialized and this leads to a NULL
>> pointer dereference in coretemp.
>>
>
> I'll see if I can figure out a way to test that.
Ok, thanks. If you need some logs, or if I should test something just
ask.
> Does 947134d9b00f
> ("x86/smpboot: Do not use smp_num_siblings in __max_logical_packages
> calculation") help?
No.
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [v6, 3/3] x86/smpboot: Fix __max_logical_packages estimate
2018-02-07 18:44 ` [v6,3/3] " Simon Gaiser
2018-02-07 19:04 ` Prarit Bhargava
@ 2018-02-07 19:04 ` Prarit Bhargava
1 sibling, 0 replies; 16+ messages in thread
From: Prarit Bhargava @ 2018-02-07 19:04 UTC (permalink / raw)
To: Simon Gaiser, xen-devel
Cc: Tom Lendacky, Vitaly Kuznetsov, Andi Kleen, Christian Borntraeger,
Peter Zijlstra, Kan Liang, x86, linux-kernel, Stephane Eranian,
He Chen, Dave Hansen, Piotr Luc, Ingo Molnar, Andy Lutomirski,
H. Peter Anvin, Arvind Yadav, Thomas Gleixner, Borislav Petkov,
Tim Chen, Mathias Krause, Kirill A. Shutemov
On 02/07/2018 01:44 PM, Simon Gaiser wrote:
> Prarit Bhargava:
>> A system booted with a small number of cores enabled per package
>> panics because the estimate of __max_logical_packages is too low.
>> This occurs when the total number of active cores across all packages
>> is less than the maximum core count for a single package.
>>
>> ie) On a 4 package system with 20 cores/package where only 4 cores
>> are enabled on each package, the value of __max_logical_packages is
>> calculated as DIV_ROUND_UP(16 / 20) = 1 and not 4.
>>
>> Calculate __max_logical_packages after the cpu enumeration has completed.
>> Use the boot cpu's data to extrapolate the number of packages.
>>
>> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Ingo Molnar <mingo@redhat.com>
>> Cc: "H. Peter Anvin" <hpa@zytor.com>
>> Cc: x86@kernel.org
>> Cc: Peter Zijlstra <peterz@infradead.org>
>> Cc: Andi Kleen <ak@linux.intel.com>
>> Cc: Dave Hansen <dave.hansen@intel.com>
>> Cc: Piotr Luc <piotr.luc@intel.com>
>> Cc: Kan Liang <kan.liang@intel.com>
>> Cc: Borislav Petkov <bp@suse.de>
>> Cc: Stephane Eranian <eranian@google.com>
>> Cc: Prarit Bhargava <prarit@redhat.com>
>> Cc: Arvind Yadav <arvind.yadav.cs@gmail.com>
>> Cc: Andy Lutomirski <luto@kernel.org>
>> Cc: Christian Borntraeger <borntraeger@de.ibm.com>
>> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
>> Cc: Tom Lendacky <thomas.lendacky@amd.com>
>> Cc: He Chen <he.chen@linux.intel.com>
>> Cc: Mathias Krause <minipli@googlemail.com>
>> Cc: Tim Chen <tim.c.chen@linux.intel.com>
>> Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
>> ---
>> arch/x86/kernel/smpboot.c | 55 +++++++++--------------------------------------
>> 1 file changed, 10 insertions(+), 45 deletions(-)
>>
>> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
>> index 838d36ff7ba6..2e3c5a394e79 100644
>> --- a/arch/x86/kernel/smpboot.c
>> +++ b/arch/x86/kernel/smpboot.c
>> @@ -308,12 +308,6 @@ int topology_update_package_map(unsigned int pkg, unsigned int cpu)
>> if (new >= 0)
>> goto found;
>>
>> - if (logical_packages >= __max_logical_packages) {
>> - pr_warn("Package %u of CPU %u exceeds BIOS package data %u.\n",
>> - logical_packages, cpu, __max_logical_packages);
>> - return -ENOSPC;
>> - }
>> -
>> new = logical_packages++;
>> if (new != pkg)
>> pr_info("CPU %u Converting physical %u to logical package %u\n",
>> @@ -323,44 +317,6 @@ int topology_update_package_map(unsigned int pkg, unsigned int cpu)
>> return 0;
>> }
>>
>> -static void __init smp_init_package_map(struct cpuinfo_x86 *c, unsigned int cpu)
>> -{
>> - unsigned int ncpus;
>> -
>> - /*
>> - * Today neither Intel nor AMD support heterogenous systems. That
>> - * might change in the future....
>> - *
>> - * While ideally we'd want '* smp_num_siblings' in the below @ncpus
>> - * computation, this won't actually work since some Intel BIOSes
>> - * report inconsistent HT data when they disable HT.
>> - *
>> - * In particular, they reduce the APIC-IDs to only include the cores,
>> - * but leave the CPUID topology to say there are (2) siblings.
>> - * This means we don't know how many threads there will be until
>> - * after the APIC enumeration.
>> - *
>> - * By not including this we'll sometimes over-estimate the number of
>> - * logical packages by the amount of !present siblings, but this is
>> - * still better than MAX_LOCAL_APIC.
>> - *
>> - * We use total_cpus not nr_cpu_ids because nr_cpu_ids can be limited
>> - * on the command line leading to a similar issue as the HT disable
>> - * problem because the hyperthreads are usually enumerated after the
>> - * primary cores.
>> - */
>> - ncpus = boot_cpu_data.x86_max_cores;
>> - if (!ncpus) {
>> - pr_warn("x86_max_cores == zero !?!?");
>> - ncpus = 1;
>> - }
>> -
>> - __max_logical_packages = DIV_ROUND_UP(total_cpus, ncpus);
>> - pr_info("Max logical packages: %u\n", __max_logical_packages);
>> -
>> - topology_update_package_map(c->phys_proc_id, cpu);
>> -}
>> -
>> void __init smp_store_boot_cpu_info(void)
>> {
>> int id = 0; /* CPU 0 */
>> @@ -368,7 +324,7 @@ void __init smp_store_boot_cpu_info(void)
>>
>> *c = boot_cpu_data;
>> c->cpu_index = id;
>> - smp_init_package_map(c, id);
>> + topology_update_package_map(c->phys_proc_id, id);
>> cpu_data(id).set = 1;
>> }
>>
>> @@ -1371,7 +1327,16 @@ void __init native_smp_prepare_boot_cpu(void)
>>
>> void __init native_smp_cpus_done(unsigned int max_cpus)
>> {
>> + int ncpus;
>> +
>> pr_debug("Boot done\n");
>> + /*
>> + * Today neither Intel nor AMD support heterogenous systems so
>> + * extrapolate the boot cpu's data to all packages.
>> + */
>> + ncpus = cpu_data(0).booted_cores * smp_num_siblings;
>> + __max_logical_packages = DIV_ROUND_UP(nr_cpu_ids, ncpus);
>> + pr_info("Max logical packages: %u\n", __max_logical_packages);
>>
>> if (x86_has_numa_in_package)
>> set_sched_topology(x86_numa_in_package_topology);
>
> This breaks booting as Xen PV domain for me. The problem seems to be
> that native_smp_cpus_done() is never called on a PV domain. So
> __max_logical_packages is uninitialized and this leads to a NULL
> pointer dereference in coretemp.
>
I'll see if I can figure out a way to test that. Does 947134d9b00f
("x86/smpboot: Do not use smp_num_siblings in __max_logical_packages
calculation") help?
P.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 16+ messages in thread