mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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;
 

  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®