public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Sohil Mehta <sohil.mehta@intel.com>, LKML <linux-kernel@vger.kernel.org>
Cc: x86@kernel.org, Tom Lendacky <thomas.lendacky@amd.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Arjan van de Ven <arjan@linux.intel.com>,
	Huang Rui <ray.huang@amd.com>, Juergen Gross <jgross@suse.com>,
	Dimitri Sivanich <dimitri.sivanich@hpe.com>,
	Michael Kelley <mikelley@microsoft.com>,
	K Prateek Nayak <kprateek.nayak@amd.com>,
	Kan Liang <kan.liang@linux.intel.com>,
	Zhang Rui <rui.zhang@intel.com>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Feng Tang <feng.tang@intel.com>,
	Andy Shevchenko <andy@infradead.org>
Subject: Re: [patch 00/53] x86/topology: The final installment
Date: Tue, 08 Aug 2023 21:10:41 +0200	[thread overview]
Message-ID: <87h6p9l58u.ffs@tglx> (raw)
In-Reply-To: <c8ca9e16-ce03-1fe0-cf9f-f6cc2302dbac@intel.com>

On Tue, Aug 08 2023 at 11:29, Sohil Mehta wrote:
> On 8/7/2023 6:52 AM, Thomas Gleixner wrote:
> However, I am a bit confused with the dmesg results.
>
> Dmesg output
> ------------
> CPU topo: Max. logical packages:   4
> CPU topo: Max. logical dies:       4
> CPU topo: Max. dies per package:   1
> CPU topo: Max. threads per core:   2
> CPU topo: Num. cores per package:    16
> CPU topo: Num. threads per package:  32

That's indeed weird. Can you please provide:

     - the output of 'cpuid -r'
     - the output of /sys/kernel/debug/x86/topo/domains
     - the APIC IDs of all CPUs (see below patch)

> Questions
> ---------
> 1) Before this series, the Max logical packages used to be logged as 8
> in dmesg. But now it shows up as 4. Is that expected?
> To me, it seems that to get to 160 potential CPUs with 10cores/20threads
> per package, the Max logical packages should be 8.

As the number of cores per package is not consistent, this is not a
surprise. 160/32 = 5, but yes something is fishy there.

Oh. Is this perhaps one of those machines where the APICs are enumerated
twice. Can you apply the patch below?

The ACPI part is a modified variant of:

    https://lore.kernel.org/r/23ccb5aad770fb52014dca9fb1e4353b5c3cede9.camel@intel.com

Please apply the topology hunks first without the ACPI changes and then
try the ACPI change on top.

Thanks,

        tglx
---
 arch/x86/kernel/acpi/boot.c    |   31 ++++++++++++++++---------------
 arch/x86/kernel/cpu/topology.c |    2 ++
 2 files changed, 18 insertions(+), 15 deletions(-)

--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -171,6 +171,8 @@ static bool __init acpi_is_processor_usa
 	return false;
 }
 
+static bool has_lapic_cpus;
+
 static int __init
 acpi_parse_x2apic(union acpi_subtable_headers *header, const unsigned long end)
 {
@@ -241,6 +243,14 @@ acpi_parse_lapic(union acpi_subtable_hea
 		return 0;
 
 	/*
+	 * According to https://uefi.org/specs/ACPI/6.5/05_ACPI_Software_Programming_Model.html#processor-local-x2apic-structure
+	 * when MADT provides both valid LAPIC and x2APIC entries, the APIC ID
+	 * in x2APIC must be equal or greater than 0xff.
+	 */
+	if (has_lapic_cpus && apic_id < 0xff)
+		return 0;
+
+	/*
 	 * We need to register disabled CPU as well to permit
 	 * counting disabled CPUs. This allows us to size
 	 * cpus_possible_map more accurately, to permit
@@ -1084,21 +1094,12 @@ static int __init acpi_parse_madt_lapic_
 				      acpi_parse_sapic, MAX_LOCAL_APIC);
 
 	if (!count) {
-		memset(madt_proc, 0, sizeof(madt_proc));
-		madt_proc[0].id = ACPI_MADT_TYPE_LOCAL_APIC;
-		madt_proc[0].handler = acpi_parse_lapic;
-		madt_proc[1].id = ACPI_MADT_TYPE_LOCAL_X2APIC;
-		madt_proc[1].handler = acpi_parse_x2apic;
-		ret = acpi_table_parse_entries_array(ACPI_SIG_MADT,
-				sizeof(struct acpi_table_madt),
-				madt_proc, ARRAY_SIZE(madt_proc), MAX_LOCAL_APIC);
-		if (ret < 0) {
-			pr_err("Error parsing LAPIC/X2APIC entries\n");
-			return ret;
-		}
-
-		count = madt_proc[0].count;
-		x2count = madt_proc[1].count;
+		count = acpi_table_parse_madt(ACPI_MADT_TYPE_LOCAL_LAPIC,
+					acpi_parse_lapic, MAX_LOCAL_APIC);
+		if (count)
+			has_lapic_cpus = true;
+		x2count = acpi_table_parse_madt(ACPI_MADT_TYPE_LOCAL_X2APIC,
+					acpi_parse_x2apic, MAX_LOCAL_APIC);
 	}
 	if (!count && !x2count) {
 		pr_err("No LAPIC entries present\n");
--- a/arch/x86/kernel/cpu/topology.c
+++ b/arch/x86/kernel/cpu/topology.c
@@ -159,6 +159,8 @@ void __init topology_register_apic(u32 a
 		return;
 	}
 
+	pr_info("Register %03x %d\n", apic_id, present);
+
 	if (present) {
 		/*
 		 * Prevent double registration, which is valid in case of


  reply	other threads:[~2023-08-08 19:40 UTC|newest]

Thread overview: 98+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-07 13:52 [patch 00/53] x86/topology: The final installment Thomas Gleixner
2023-08-07 13:52 ` [patch 01/53] x86/cpu/topology: Cure off by one in fake_topology() Thomas Gleixner
2023-08-07 13:52 ` [patch 02/53] x86/cpu/topology: Make the APIC mismatch warnings complete Thomas Gleixner
2023-08-07 14:28   ` Arjan van de Ven
2023-08-07 14:54     ` Thomas Gleixner
2023-08-07 13:52 ` [patch 03/53] x86/platform/ce4100: Dont override x86_init.mpparse.setup_ioapic_ids Thomas Gleixner
2023-08-07 15:20   ` Andy Shevchenko
2023-08-07 13:52 ` [patch 04/53] x86/ioapic: Replace some more set bit nonsense Thomas Gleixner
2023-08-07 13:52 ` [patch 05/53] x86/apic: Get rid of get_physical_broadcast() Thomas Gleixner
2023-08-07 15:24   ` Andy Shevchenko
2023-08-07 13:52 ` [patch 06/53] x86/ioapic: Make io_apic_get_unique_id() simpler Thomas Gleixner
2023-08-07 13:52 ` [patch 07/53] x86/ioapic: Simplify setup_ioapic_ids_from_mpc_nocheck() Thomas Gleixner
2023-08-07 13:52 ` [patch 08/53] x86/apic: Remove check_apicid_used() and ioapic_phys_id_map() Thomas Gleixner
2023-08-07 13:52 ` [patch 09/53] x86/mpparse: Rename default_find_smp_config() Thomas Gleixner
2023-08-07 16:03   ` Andy Shevchenko
2023-08-07 17:21     ` Thomas Gleixner
2023-08-07 13:52 ` [patch 10/53] x86/mpparse: Provide separate early/late callbacks Thomas Gleixner
2023-08-07 13:52 ` [patch 11/53] x86/mpparse: Prepare for callback separation Thomas Gleixner
2023-08-07 13:52 ` [patch 12/53] x86/dtb: Rename x86_dtb_init() Thomas Gleixner
2023-08-07 13:52 ` [patch 13/53] x86/platform/ce4100: Prepare for separate mpparse callbacks Thomas Gleixner
2023-08-07 13:52 ` [patch 14/53] x86/platform/intel-mid: " Thomas Gleixner
2023-08-07 16:07   ` Andy Shevchenko
2023-08-07 13:52 ` [patch 15/53] x86/jailhouse: " Thomas Gleixner
2023-08-07 13:52 ` [patch 16/53] x86/xen/smp_pv: " Thomas Gleixner
2023-08-07 13:53 ` [patch 17/53] x86/mpparse: Switch to new init callbacks Thomas Gleixner
2023-08-07 13:53 ` [patch 18/53] x86/mm/numa: Move early mptable evaluation into common code Thomas Gleixner
2023-08-07 13:53 ` [patch 19/53] x86/mpparse: Remove the physid_t bitmap wrapper Thomas Gleixner
2023-08-08 11:37   ` Andy Shevchenko
2023-08-07 13:53 ` [patch 20/53] x86/apic: Remove the pointless writeback of boot_cpu_physical_apicid Thomas Gleixner
2023-08-07 13:53 ` [patch 21/53] x86/apic: Remove yet another dubious callback Thomas Gleixner
2023-08-07 13:53 ` [patch 22/53] x86/apic: Use a proper define for invalid ACPI CPU ID Thomas Gleixner
2023-08-07 13:53 ` [patch 23/53] x86/cpu/topology: Move registration out of APIC code Thomas Gleixner
2023-08-07 13:53 ` [patch 24/53] x86/cpu/topology: Provide separate APIC registration functions Thomas Gleixner
2023-08-11 12:32   ` Zhang, Rui
2023-08-07 13:53 ` [patch 25/53] x86/acpi: Use new " Thomas Gleixner
2023-08-07 15:27   ` Peter Zijlstra
2023-08-07 15:35     ` Andrew Cooper
2023-08-07 15:41     ` Thomas Gleixner
2023-08-07 13:53 ` [patch 26/53] x86/jailhouse: Use new APIC registration function Thomas Gleixner
2023-08-07 13:53 ` [patch 27/53] x86/of: Use new APIC registration functions Thomas Gleixner
2023-08-07 13:53 ` [patch 28/53] x86/mpparse: Use new APIC registration function Thomas Gleixner
2023-08-07 13:53 ` [patch 29/53] x86/acpi: Dont invoke topology_register_apic() for XEN PV Thomas Gleixner
2023-08-07 13:53 ` [patch 30/53] x86/xen/smp_pv: Register fake APICs Thomas Gleixner
2023-08-07 13:53 ` [patch 31/53] x86/cpu/topology: Confine topology information Thomas Gleixner
2023-08-07 13:53 ` [patch 32/53] x86/cpu/topology: Simplify APIC registration Thomas Gleixner
2023-08-07 13:53 ` [patch 33/53] x86/cpu/topology: Use a data structure for topology info Thomas Gleixner
2023-08-07 13:53 ` [patch 34/53] x86/smpboot: Make error message actually useful Thomas Gleixner
2023-08-07 13:53 ` [patch 35/53] x86/cpu/topology: Sanitize the APIC admission logic Thomas Gleixner
2023-08-07 13:53 ` [patch 36/53] x86/cpu/topology: Rework possible CPU management Thomas Gleixner
2023-08-14  8:29   ` Zhang, Rui
2023-08-07 13:53 ` [patch 37/53] x86/cpu: Detect real BSP on crash kernels Thomas Gleixner
2024-01-08 14:11   ` Zhang, Rui
2024-01-08 14:54     ` Thomas Gleixner
2024-01-08 16:13       ` Thomas Gleixner
2024-01-09  1:54         ` Zhang, Rui
2024-01-10 14:19           ` Thomas Gleixner
2024-01-10 15:14             ` Thomas Gleixner
2024-01-11  1:52               ` Zhang, Rui
2024-01-12  9:14               ` Zhang, Rui
2024-01-12 15:39                 ` Thomas Gleixner
2024-01-13  7:35                   ` Zhang, Rui
2024-01-15  9:41                     ` Thomas Gleixner
2023-08-07 13:53 ` [patch 38/53] x86/topology: Add a mechanism to track topology via APIC IDs Thomas Gleixner
2023-08-07 13:53 ` [patch 39/53] x86/cpu/topology: Reject unknown APIC IDs on ACPI hotplug Thomas Gleixner
2023-08-07 13:53 ` [patch 40/53] x86/cpu/topology: Assign hotpluggable CPUIDs during init Thomas Gleixner
2023-08-07 13:53 ` [patch 41/53] x86/xen/smp_pv: Count number of vCPUs early Thomas Gleixner
2023-08-07 13:53 ` [patch 42/53] x86/cpu/topology: Let XEN/PV use topology from CPUID/MADT Thomas Gleixner
2023-08-07 13:53 ` [patch 43/53] x86/cpu/topology: Use topology bitmaps for sizing Thomas Gleixner
2023-08-07 13:53 ` [patch 44/53] x86/cpu/topology: Mop up primary thread mask handling Thomas Gleixner
2023-08-07 13:53 ` [patch 45/53] x86/cpu/topology: Simplify cpu_mark_primary_thread() Thomas Gleixner
2023-08-07 13:53 ` [patch 46/53] x86/cpu/topology: Provide logical pkg/die mapping Thomas Gleixner
2023-08-07 13:53 ` [patch 47/53] x86/cpu/topology: Use topology logical mapping mechanism Thomas Gleixner
2023-08-07 13:53 ` [patch 48/53] x86/cpu/topology: Retrieve cores per package from topology bitmaps Thomas Gleixner
2023-08-07 13:53 ` [patch 49/53] x86: Use topology functions instead of smp_num_siblings where applicable Thomas Gleixner
2023-08-07 13:53 ` [patch 50/53] x86/cpu/topology: Rename smp_num_siblings Thomas Gleixner
2023-08-07 13:53 ` [patch 51/53] x86/cpu/topology: Rename topology_max_die_per_package() Thomas Gleixner
2023-08-07 13:53 ` [patch 52/53] x86/cpu/topology: Provide __num_[cores|threads]_per_package Thomas Gleixner
2023-08-07 13:53 ` [patch 53/53] x86/cpu/topology: Get rid of cpuinfo::x86_max_cores Thomas Gleixner
2023-08-11 15:44   ` Zhang, Rui
2023-12-14 14:00   ` Zhang, Rui
2023-08-08  7:40 ` [patch 00/53] x86/topology: The final installment Juergen Gross
2023-08-08 11:20   ` Andrew Cooper
2023-08-08 18:55     ` Thomas Gleixner
2023-08-08 18:29 ` Sohil Mehta
2023-08-08 19:10   ` Thomas Gleixner [this message]
2023-08-08 20:30     ` Sohil Mehta
2023-08-08 20:41       ` Thomas Gleixner
2023-08-08 22:10         ` Peter Zijlstra
2023-08-08 22:58           ` Sohil Mehta
2023-08-08 23:20             ` Thomas Gleixner
2023-08-09 16:55               ` Sohil Mehta
2023-08-10  3:28               ` Zhang, Rui
2023-08-09 16:50             ` Qiuxu Zhuo
2023-08-09 17:23               ` Sohil Mehta
2023-08-10  1:33                 ` Zhuo, Qiuxu
2023-08-08 20:57       ` Thomas Gleixner
2023-08-09 16:12 ` Qiuxu Zhuo
2023-08-12 13:51 ` Michael Kelley (LINUX)

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=87h6p9l58u.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=andrew.cooper3@citrix.com \
    --cc=andy@infradead.org \
    --cc=arjan@linux.intel.com \
    --cc=dimitri.sivanich@hpe.com \
    --cc=feng.tang@intel.com \
    --cc=jgross@suse.com \
    --cc=kan.liang@linux.intel.com \
    --cc=kprateek.nayak@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikelley@microsoft.com \
    --cc=paulmck@kernel.org \
    --cc=ray.huang@amd.com \
    --cc=rui.zhang@intel.com \
    --cc=sohil.mehta@intel.com \
    --cc=thomas.lendacky@amd.com \
    --cc=x86@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox