From: "Chang S. Bae" <chang.seok.bae@intel.com>
To: Dave Hansen <dave.hansen@intel.com>, <x86@kernel.org>
Cc: <tglx@linutronix.de>, <mingo@redhat.com>, <bp@alien8.de>,
<dave.hansen@linux.intel.com>, <colinmitchell@google.com>,
<chao.gao@intel.com>, <abusse@amazon.de>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 2/6] x86/microcode/intel: Establish staging control logic
Date: Thu, 14 Aug 2025 11:30:41 -0700 [thread overview]
Message-ID: <5873ddb4-c219-487a-9ccb-0d3eda02d97b@intel.com> (raw)
In-Reply-To: <04cb59cb-e9ed-489c-b36f-6c6209b2e93f@intel.com>
[-- Attachment #1: Type: text/plain, Size: 2327 bytes --]
On 8/13/2025 1:55 PM, Dave Hansen wrote:
>
> But that's not the problem. The issue is that this line of code:
>
> #define cpu_primary_thread_mask cpu_none_mask
With CONFIG_SMP=n, on the core side (include/linux/cpu_smt.h), the code
clarifies there is no SMT:
# define cpu_smt_control (CPU_SMT_NOT_IMPLEMENTED)
This leads kernel/cpu.c to return an empty mask:
static inline const struct cpumask *cpuhp_get_primary_thread_mask(void)
{
return cpu_none_mask;
}
On the x86 side, the definition is explicit that “primary threads” are
SMT threads (arch/x86/kernel/smpboot.c):
/* CPUs which are the primary SMT threads */
struct cpumask __cpu_primary_thread_mask __read_mostly;
And via ifdeffery, this mask is only available to SMP kernels.
So it seems I had been subscribing this model -- no primary threads
without SMP.
> reads as 100% bogus to me. Even on !SMP kernels,
> 'cpu_primary_thread_mask' should have one CPU in it. Right? The _one_
> thread that's present is a primary thread. If this were a mask for
> secondary threads, 'cpu_none_mask' would make sense. But it's not.
Your confidence made me take another look.
Digging into the history, I found that x86 used to have this in the !SMP
case:
static inline bool topology_is_primary_thread(unsigned int cpu)
{
return true;
}
That stayed until the recent commit 4b455f59945aa ("cpu/SMT: Provide a
default topology_is_primary_thread()"), which now defines it in
include/linux/topology.h with this telling comment:
/*
* When disabling SMT, the primary thread of the SMT will remain
* enabled/active. Architectures that have a special primary thread
* (e.g. x86) need to override this function. ...
*/
This comment basically supports your point.
> So could we please make use 'cpu_primary_thread_mask' is getting defined
> correctly whether it's really getting compiled into the end image or not?
Given that, I’m thinking of simplifying the x86 side a bit -- by making
the primary thread mask configured and available regardless of
CONFIG_SMP, matching the behavior of other cpumasks. And its relevant
helpers are also available, like in the attached diff.
I think the change still aligns x86 with the core code -- especially
with the note in topology_is_primary_thread(). With that, the user may
be introduced here.
[-- Attachment #2: tmp.diff --]
[-- Type: text/plain, Size: 2947 bytes --]
diff --git a/arch/x86/include/asm/topology.h b/arch/x86/include/asm/topology.h
index 6c79ee7c0957..281252af6e9d 100644
--- a/arch/x86/include/asm/topology.h
+++ b/arch/x86/include/asm/topology.h
@@ -218,6 +218,12 @@ static inline unsigned int topology_amd_nodes_per_pkg(void)
return __amd_nodes_per_pkg;
}
+#else /* CONFIG_SMP */
+static inline int topology_phys_to_logical_pkg(unsigned int pkg) { return 0; }
+static inline int topology_max_smt_threads(void) { return 1; }
+static inline unsigned int topology_amd_nodes_per_pkg(void) { return 1; }
+#endif /* !CONFIG_SMP */
+
extern struct cpumask __cpu_primary_thread_mask;
#define cpu_primary_thread_mask ((const struct cpumask *)&__cpu_primary_thread_mask)
@@ -231,12 +237,6 @@ static inline bool topology_is_primary_thread(unsigned int cpu)
}
#define topology_is_primary_thread topology_is_primary_thread
-#else /* CONFIG_SMP */
-static inline int topology_phys_to_logical_pkg(unsigned int pkg) { return 0; }
-static inline int topology_max_smt_threads(void) { return 1; }
-static inline unsigned int topology_amd_nodes_per_pkg(void) { return 1; }
-#endif /* !CONFIG_SMP */
-
static inline void arch_fix_phys_package_id(int num, u32 slot)
{
}
diff --git a/arch/x86/kernel/cpu/topology.c b/arch/x86/kernel/cpu/topology.c
index e35ccdc84910..946004d7dd1d 100644
--- a/arch/x86/kernel/cpu/topology.c
+++ b/arch/x86/kernel/cpu/topology.c
@@ -52,6 +52,9 @@ u32 cpuid_to_apicid[] __ro_after_init = { [0 ... NR_CPUS - 1] = BAD_APICID, };
/* Bitmaps to mark registered APICs at each topology domain */
static struct { DECLARE_BITMAP(map, MAX_LOCAL_APIC); } apic_maps[TOPO_MAX_DOMAIN] __ro_after_init;
+/* CPUs which are the primary SMT threads */
+struct cpumask __cpu_primary_thread_mask __read_mostly;
+
/*
* Keep track of assigned, disabled and rejected CPUs. Present assigned
* with 1 as CPU #0 is reserved for the boot CPU.
@@ -75,15 +78,11 @@ bool arch_match_cpu_phys_id(int cpu, u64 phys_id)
return phys_id == (u64)cpuid_to_apicid[cpu];
}
-#ifdef CONFIG_SMP
static void cpu_mark_primary_thread(unsigned int cpu, unsigned int apicid)
{
if (!(apicid & (__max_threads_per_core - 1)))
cpumask_set_cpu(cpu, &__cpu_primary_thread_mask);
}
-#else
-static inline void cpu_mark_primary_thread(unsigned int cpu, unsigned int apicid) { }
-#endif
/*
* Convert the APIC ID to a domain level ID by masking out the low bits
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 33e166f6ab12..7804175d2d87 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -103,9 +103,6 @@ EXPORT_PER_CPU_SYMBOL(cpu_core_map);
DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_die_map);
EXPORT_PER_CPU_SYMBOL(cpu_die_map);
-/* CPUs which are the primary SMT threads */
-struct cpumask __cpu_primary_thread_mask __read_mostly;
-
/* Representing CPUs for which sibling maps can be computed */
static cpumask_var_t cpu_sibling_setup_mask;
next prev parent reply other threads:[~2025-08-14 18:30 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-20 23:40 [PATCH v2 0/6] x86: Support for Intel Microcode Staging Feature Chang S. Bae
2025-03-20 23:40 ` [PATCH v2 1/6] x86/microcode: Introduce staging step to reduce late-loading time Chang S. Bae
2025-03-20 23:40 ` [PATCH v2 2/6] x86/microcode/intel: Define staging state struct Chang S. Bae
2025-03-20 23:40 ` [PATCH v2 3/6] x86/microcode/intel: Establish staging control logic Chang S. Bae
2025-03-21 21:18 ` [PATCH v2a " Chang S. Bae
2025-03-26 7:35 ` Chao Gao
2025-03-26 18:43 ` Chang S. Bae
2025-03-27 1:44 ` Chao Gao
2025-03-28 14:12 ` Chang S. Bae
2025-03-20 23:40 ` [PATCH v2 4/6] x86/microcode/intel: Implement staging handler Chang S. Bae
2025-03-21 0:15 ` Dave Hansen
2025-03-21 21:19 ` [PATCH v2a " Chang S. Bae
2025-03-26 8:34 ` Chao Gao
2025-03-26 18:43 ` Chang S. Bae
2025-03-21 21:19 ` [PATCH v2 " Chang S. Bae
2025-03-20 23:40 ` [PATCH v2 5/6] x86/microcode/intel: Support mailbox transfer Chang S. Bae
2025-03-21 21:19 ` [PATCH v2a " Chang S. Bae
2025-03-27 3:32 ` [PATCH v2 " Chao Gao
2025-03-27 14:11 ` Chang S. Bae
2025-03-31 19:16 ` Dave Hansen
2025-03-20 23:40 ` [PATCH v2 6/6] x86/microcode/intel: Enable staging when available Chang S. Bae
2025-04-09 23:27 ` [PATCH v3 0/6] x86: Support for Intel Microcode Staging Feature Chang S. Bae
2025-04-09 23:27 ` [PATCH v3 1/6] x86/microcode: Introduce staging step to reduce late-loading time Chang S. Bae
2025-04-09 23:27 ` [PATCH v3 2/6] x86/microcode/intel: Establish staging control logic Chang S. Bae
2025-04-09 23:27 ` [PATCH v3 3/6] x86/microcode/intel: Define staging state struct Chang S. Bae
2025-04-09 23:27 ` [PATCH v3 4/6] x86/microcode/intel: Implement staging handler Chang S. Bae
2025-04-09 23:27 ` [PATCH v3 5/6] x86/microcode/intel: Support mailbox transfer Chang S. Bae
2025-04-16 14:14 ` Chao Gao
2025-04-16 17:22 ` Chang S. Bae
2025-04-16 17:37 ` Dave Hansen
2025-04-09 23:27 ` [PATCH v3 6/6] x86/microcode/intel: Enable staging when available Chang S. Bae
2025-08-13 17:26 ` [PATCH v4 0/6] x86: Support for Intel Microcode Staging Feature Chang S. Bae
2025-08-13 17:26 ` [PATCH v4 1/6] x86/microcode: Introduce staging step to reduce late-loading time Chang S. Bae
2025-08-18 7:45 ` Chao Gao
2025-08-13 17:26 ` [PATCH v4 2/6] x86/microcode/intel: Establish staging control logic Chang S. Bae
2025-08-13 18:21 ` Dave Hansen
2025-08-13 20:46 ` Chang S. Bae
2025-08-13 20:55 ` Dave Hansen
2025-08-14 18:30 ` Chang S. Bae [this message]
2025-08-22 22:39 ` [PATCH] x86/cpu/topology: Make primary thread mask available with SMP=n Chang S. Bae
2025-08-23 16:05 ` Chang S. Bae
2025-08-22 22:39 ` [PATCH v4a 2/6] x86/microcode/intel: Establish staging control logic Chang S. Bae
2025-08-22 23:34 ` Dave Hansen
2025-08-13 17:26 ` [PATCH v4 3/6] x86/microcode/intel: Define staging state struct Chang S. Bae
2025-08-13 18:25 ` Dave Hansen
2025-08-22 22:39 ` [PATCH v4a " Chang S. Bae
2025-08-13 17:26 ` [PATCH v4 4/6] x86/microcode/intel: Implement staging handler Chang S. Bae
2025-08-13 18:44 ` Dave Hansen
2025-08-22 22:39 ` [PATCH v4a " Chang S. Bae
2025-08-13 17:26 ` [PATCH v4 5/6] x86/microcode/intel: Support mailbox transfer Chang S. Bae
2025-08-13 19:07 ` Dave Hansen
2025-08-22 22:40 ` [PATCH v4a " Chang S. Bae
2025-08-13 17:26 ` [PATCH v4 6/6] x86/microcode/intel: Enable staging when available Chang S. Bae
2025-08-18 8:35 ` Chao Gao
2025-08-22 22:42 ` Chang S. Bae
2025-08-13 19:08 ` [PATCH v4 0/6] x86: Support for Intel Microcode Staging Feature Dave Hansen
2025-08-23 15:52 ` [PATCH v5 0/7] " Chang S. Bae
2025-08-23 15:52 ` [PATCH v5 1/7] x86/cpu/topology: Make primary thread mask available with SMP=n Chang S. Bae
2025-08-23 15:52 ` [PATCH v5 2/7] x86/microcode: Introduce staging step to reduce late-loading time Chang S. Bae
2025-09-04 12:08 ` Borislav Petkov
2025-09-05 0:06 ` Chang S. Bae
2025-08-23 15:52 ` [PATCH v5 3/7] x86/microcode/intel: Establish staging control logic Chang S. Bae
2025-09-04 12:13 ` Borislav Petkov
2025-09-05 0:04 ` Chang S. Bae
2025-09-05 11:13 ` Borislav Petkov
2025-09-05 16:31 ` Chang S. Bae
2025-08-23 15:52 ` [PATCH v5 4/7] x86/microcode/intel: Define staging state struct Chang S. Bae
2025-09-04 13:48 ` Borislav Petkov
2025-09-05 0:05 ` Chang S. Bae
2025-08-23 15:52 ` [PATCH v5 5/7] x86/microcode/intel: Implement staging handler Chang S. Bae
2025-09-10 18:33 ` Borislav Petkov
2025-09-10 21:31 ` Chang S. Bae
2025-08-23 15:52 ` [PATCH v5 6/7] x86/microcode/intel: Support mailbox transfer Chang S. Bae
2025-09-12 16:34 ` Borislav Petkov
2025-09-13 0:51 ` Chang S. Bae
2025-09-13 19:01 ` Borislav Petkov
2025-08-23 15:52 ` [PATCH v5 7/7] x86/microcode/intel: Enable staging when available Chang S. Bae
2025-08-26 22:13 ` [PATCH v5 0/7] x86: Support for Intel Microcode Staging Feature Luck, Tony
2025-08-26 22:15 ` Chang S. Bae
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=5873ddb4-c219-487a-9ccb-0d3eda02d97b@intel.com \
--to=chang.seok.bae@intel.com \
--cc=abusse@amazon.de \
--cc=bp@alien8.de \
--cc=chao.gao@intel.com \
--cc=colinmitchell@google.com \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--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
all inboxes | Powered by JetHome®