From: Brian Gerst <brgerst@gmail.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org
Cc: David Woodhouse <dwmw2@infradead.org>,
Usama Arif <usama.arif@bytedance.com>,
Thomas Gleixner <tglx@linutronix.de>,
Borislav Petkov <bp@alien8.de>, "H . Peter Anvin" <hpa@zytor.com>,
Peter Zijlstra <peterz@infradead.org>,
Andy Lutomirski <luto@kernel.org>, Ingo Molnar <mingo@kernel.org>,
Brian Gerst <brgerst@gmail.com>,
David Woodhouse <dwmw@amazon.co.uk>
Subject: [PATCH v2 4/5] x86/smpboot: Simplify boot CPU setup
Date: Fri, 24 Feb 2023 10:42:34 -0500 [thread overview]
Message-ID: <20230224154235.277350-5-brgerst@gmail.com> (raw)
In-Reply-To: <20230224154235.277350-1-brgerst@gmail.com>
Now that the per-cpu GSBASE, stack, and GDT descriptor can be derived
dynamically by CPU number, the boot CPU can use a fixed CPU number and
take the same path as secondary CPUs.
Signed-off-by: Brian Gerst <brgerst@gmail.com>
Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Tested-by: Usama Arif <usama.arif@bytedance.com>
Signed-off-by: Usama Arif <usama.arif@bytedance.com>
---
arch/x86/kernel/head_64.S | 24 +++++++-----------------
1 file changed, 7 insertions(+), 17 deletions(-)
diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index 9ed87ba0609f..8bd29ab523dd 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -235,11 +235,6 @@ SYM_INNER_LABEL(secondary_startup_64_no_verify, SYM_L_GLOBAL)
ANNOTATE_NOENDBR // above
#ifdef CONFIG_SMP
- /* Is this the boot CPU coming up? */
- movl smpboot_control(%rip), %edx
- testl $STARTUP_SECONDARY, %edx
- jz .Linit_cpu0_data
-
/*
* For parallel boot, the APIC ID is retrieved from CPUID, and then
* used to look up the CPU number. For booting a single CPU, the
@@ -250,13 +245,13 @@ SYM_INNER_LABEL(secondary_startup_64_no_verify, SYM_L_GLOBAL)
* Bit 29 STARTUP_APICID_CPUID_01 flag (use CPUID 0x01)
* Bit 0-24 CPU# if STARTUP_APICID_CPUID_xx flags are not set
*/
- testl $STARTUP_APICID_CPUID_0B, %edx
+ movl smpboot_control(%rip), %ecx
+ testl $STARTUP_APICID_CPUID_0B, %ecx
jnz .Luse_cpuid_0b
- testl $STARTUP_APICID_CPUID_01, %edx
+ testl $STARTUP_APICID_CPUID_01, %ecx
jnz .Luse_cpuid_01
- andl $0x0FFFFFFF, %edx
- movl %edx, %ecx
- jmp .Linit_cpu_data
+ andl $0x0FFFFFFF, %ecx
+ jmp .Lsetup_cpu
.Luse_cpuid_01:
mov $0x01, %eax
@@ -277,7 +272,7 @@ SYM_INNER_LABEL(secondary_startup_64_no_verify, SYM_L_GLOBAL)
.Lfind_cpunr:
cmpl (%rbx,%rcx,4), %edx
- jz .Linit_cpu_data
+ jz .Lsetup_cpu
inc %ecx
cmpl nr_cpu_ids(%rip), %ecx
jb .Lfind_cpunr
@@ -291,18 +286,13 @@ SYM_INNER_LABEL(secondary_startup_64_no_verify, SYM_L_GLOBAL)
hlt
jmp 1b
-.Linit_cpu0_data:
- movq __per_cpu_offset(%rip), %rdx
- jmp .Lsetup_cpu
-
-.Linit_cpu_data:
+.Lsetup_cpu:
/* Get the per cpu offset for the given CPU# which is in ECX */
movq __per_cpu_offset(,%rcx,8), %rdx
#else
xorl %edx, %edx
#endif /* CONFIG_SMP */
-.Lsetup_cpu:
/*
* Setup a boot time stack - Any secondary CPU will have lost its stack
* by now because the cr3-switch above unmaps the real-mode stack
--
2.39.2
next prev parent reply other threads:[~2023-02-24 15:42 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-24 15:42 [PATCH v2 0/5] x86-64: Remove global variables from boot Brian Gerst
2023-02-24 15:42 ` [PATCH v2 1/5] x86/smpboot: Remove initial_stack on 64-bit Brian Gerst
2023-02-24 15:42 ` [PATCH v2 2/5] x86/smpboot: Remove early_gdt_descr " Brian Gerst
2023-02-24 15:42 ` [PATCH v2 3/5] x86/smpboot: Remove initial_gs Brian Gerst
2023-02-24 15:42 ` Brian Gerst [this message]
2023-02-24 15:42 ` [PATCH v2 5/5] x86/smpboot: Remove STARTUP_SECONDARY Brian Gerst
2023-02-24 20:40 ` [External] [PATCH v2 0/5] x86-64: Remove global variables from boot Usama Arif
2023-02-24 21:38 ` Brian Gerst
2023-02-24 21:40 ` David Woodhouse
2023-02-25 10:20 ` David Woodhouse
2023-02-25 12:47 ` Brian Gerst
2023-02-25 12:55 ` David Woodhouse
2023-02-25 13:33 ` Usama Arif
2023-02-25 13:52 ` David Woodhouse
2023-02-25 22:15 ` Usama Arif
2023-02-25 22:19 ` David Woodhouse
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=20230224154235.277350-5-brgerst@gmail.com \
--to=brgerst@gmail.com \
--cc=bp@alien8.de \
--cc=dwmw2@infradead.org \
--cc=dwmw@amazon.co.uk \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=usama.arif@bytedance.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