From nobody Sun Feb 8 04:18:02 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 47E48C6FD1C for ; Thu, 23 Mar 2023 01:57:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229964AbjCWB5N (ORCPT ); Wed, 22 Mar 2023 21:57:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37276 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229642AbjCWB5J (ORCPT ); Wed, 22 Mar 2023 21:57:09 -0400 Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 24E1D211ED for ; Wed, 22 Mar 2023 18:57:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1679536628; x=1711072628; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=S4J23vlMifTu0C/qcM5GZRfKQJI8Zib/+EwiNhOEfAU=; b=eDsCL6MjRmjnnrXgCSx5YafEprlJrZrAnfhrULGo+YV49iXj04CcfHSG h8dCn7i7SU/XOfzPWYKAou/ky6GdomMRF9m/L73lcCkRLSA7o1K0Hg4kj fYZ5ydwXf59QZtfaonvWAxk6j3xRMozwBKSJWgpKV+RuBmAaZ/VXZiU87 NVkdXwxUjUj/KCqJJZCcdvyY3zNWRnHMlqBaZpJpJ8r4d/R7BpBV7uD7E bMr92JPitl6x5koqgc7RaesPY+f1IETkpqbN0L7WQxn0X3dGuUJ8eyGX2 FLosRKWkJBIz3NVdeGD0dbsJ2l3F6btlUD/fWk7UqWaZp7VNYzeCUwOK8 w==; X-IronPort-AV: E=McAfee;i="6600,9927,10657"; a="401943931" X-IronPort-AV: E=Sophos;i="5.98,283,1673942400"; d="scan'208";a="401943931" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Mar 2023 18:57:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10657"; a="792813180" X-IronPort-AV: E=Sophos;i="5.98,283,1673942400"; d="scan'208";a="792813180" Received: from jhuan49-mobl1.ccr.corp.intel.com (HELO rzhang1-DESK.intel.com) ([10.255.31.187]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Mar 2023 18:57:03 -0700 From: Zhang Rui To: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com Cc: x86@kernel.org, linux-kernel@vger.kernel.org, zhang.jia@linux.alibaba.com, len.brown@intel.com, rui.zhang@intel.com Subject: [PATCH V3] x86/topology: fix erroneous smp_num_siblings on Intel Hybrid platform Date: Thu, 23 Mar 2023 09:56:40 +0800 Message-Id: <20230323015640.27906-1-rui.zhang@intel.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" The SMT siblings value returned by CPUID.1F SMT level EBX differs among CPUs on Intel Hybrid platforms like AlderLake and MeteorLake. It returns 2 for Pcore CPUs which have SMT siblings and returns 1 for Ecore CPUs which do not have SMT siblings. Today, the CPU boot code sets the global variable smp_num_siblings when every CPU thread is brought up. The last thread to boot will overwrite it with the number of siblings of *that* thread. That last thread to boot will "win". If the thread is a Pcore, smp_num_siblings =3D=3D 2. If it is an Ecore, smp_num_siblings =3D=3D 1. smp_num_siblings describes if the *system* supports SMT. It should specify the maximum number of SMT threads among all cores. Ensure that smp_num_siblings represents the system-wide maximum number of siblings by always increasing its value. Never allow it to decrease. On MeteorLake-P platform, this fixes a problem that the Ecore CPUs are not updated in any cpu sibling map because the system is treated as an UP system when probing Ecore CPUs. Below shows part of the CPU topology information before and after the fix, for both Pcore and Ecore CPU (cpu0 is Pcore, cpu 12 is Ecore). ... -/sys/devices/system/cpu/cpu0/topology/package_cpus:000fff -/sys/devices/system/cpu/cpu0/topology/package_cpus_list:0-11 +/sys/devices/system/cpu/cpu0/topology/package_cpus:3fffff +/sys/devices/system/cpu/cpu0/topology/package_cpus_list:0-21 ... -/sys/devices/system/cpu/cpu12/topology/package_cpus:001000 -/sys/devices/system/cpu/cpu12/topology/package_cpus_list:12 +/sys/devices/system/cpu/cpu12/topology/package_cpus:3fffff +/sys/devices/system/cpu/cpu12/topology/package_cpus_list:0-21 And this also breaks userspace tools like lscpu -Core(s) per socket: 1 -Socket(s): 11 +Core(s) per socket: 16 +Socket(s): 1 CC: stable@kernel.org Fixes: bbb65d2d365e ("x86: use cpuid vector 0xb when available for detectin= g cpu topology") Fixes: 95f3d39ccf7a ("x86/cpu/topology: Provide detect_extended_topology_ea= rly()") Suggested-by: Len Brown Signed-off-by: Zhang Rui Acked-by: Peter Zijlstra (Intel) --- V2 -> V3 Add Acked-by tag from Peter. Add Fixes tag. V1 -> V2 Improve changelog to focus on the smp_num_siblings issue. --- arch/x86/kernel/cpu/topology.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/cpu/topology.c b/arch/x86/kernel/cpu/topology.c index 5e868b62a7c4..0270925fe013 100644 --- a/arch/x86/kernel/cpu/topology.c +++ b/arch/x86/kernel/cpu/topology.c @@ -79,7 +79,7 @@ int detect_extended_topology_early(struct cpuinfo_x86 *c) * initial apic id, which also represents 32-bit extended x2apic id. */ c->initial_apicid =3D edx; - smp_num_siblings =3D LEVEL_MAX_SIBLINGS(ebx); + smp_num_siblings =3D max_t(int, smp_num_siblings, LEVEL_MAX_SIBLINGS(ebx)= ); #endif return 0; } @@ -109,7 +109,8 @@ int detect_extended_topology(struct cpuinfo_x86 *c) */ cpuid_count(leaf, SMT_LEVEL, &eax, &ebx, &ecx, &edx); c->initial_apicid =3D edx; - core_level_siblings =3D smp_num_siblings =3D LEVEL_MAX_SIBLINGS(ebx); + core_level_siblings =3D LEVEL_MAX_SIBLINGS(ebx); + smp_num_siblings =3D max_t(int, smp_num_siblings, LEVEL_MAX_SIBLINGS(ebx)= ); core_plus_mask_width =3D ht_mask_width =3D BITS_SHIFT_NEXT_LEVEL(eax); die_level_siblings =3D LEVEL_MAX_SIBLINGS(ebx); pkg_mask_width =3D die_plus_mask_width =3D BITS_SHIFT_NEXT_LEVEL(eax); --=20 2.25.1