From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161609AbcHEQRi (ORCPT ); Fri, 5 Aug 2016 12:17:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40016 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161571AbcHEQRh (ORCPT ); Fri, 5 Aug 2016 12:17:37 -0400 Date: Fri, 5 Aug 2016 11:17:33 -0500 From: Josh Poimboeuf To: Nilay Vaish Cc: Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , x86 , Linux Kernel list , Andy Lutomirski , Linus Torvalds , Steven Rostedt , Brian Gerst , Kees Cook , Peter Zijlstra , Frederic Weisbecker , Byungchul Park Subject: Re: [PATCH v2 04/44] x86/asm/head: use a common function for starting CPUs Message-ID: <20160805161733.sob3i6fnb6y7kmce@treble> References: <861123c572cd7a797bb2223f6f2734b62ee66a75.1470345772.git.jpoimboe@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Fri, 05 Aug 2016 16:17:36 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 05, 2016 at 10:41:15AM -0500, Nilay Vaish wrote: > On 4 August 2016 at 17:22, Josh Poimboeuf wrote: > > There are two different pieces of code for starting a CPU: start_cpu0() > > and the end of secondary_startup_64(). They're identical except for the > > stack setup. Combine the common parts into a shared start_cpu() > > function. > > > > Signed-off-by: Josh Poimboeuf > > --- > > arch/x86/kernel/head_64.S | 18 ++++++++---------- > > 1 file changed, 8 insertions(+), 10 deletions(-) > > > > diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S > > index aa10a53..8822c20 100644 > > --- a/arch/x86/kernel/head_64.S > > +++ b/arch/x86/kernel/head_64.S > > @@ -264,13 +264,15 @@ ENTRY(secondary_startup_64) > > movl $MSR_GS_BASE,%ecx > > movl initial_gs(%rip),%eax > > movl initial_gs+4(%rip),%edx > > - wrmsr > > + wrmsr > > > > /* rsi is pointer to real mode structure with interesting info. > > pass it to C */ > > movq %rsi, %rdi > > - > > - /* Finally jump to run C code and to be on real kernel address > > + > > +ENTRY(start_cpu) > > + /* > > + * Jump to run C code and to be on a real kernel address. > > * Since we are running on identity-mapped space we have to jump > > * to the full 64bit address, this is only possible as indirect > > * jump. In addition we need to ensure %cs is set so we make this > > @@ -307,15 +309,11 @@ ENDPROC(secondary_startup_64) > > /* > > * Boot CPU0 entry point. It's called from play_dead(). Everything has been set > > * up already except stack. We just set up stack here. Then call > > - * start_secondary(). > > + * start_secondary() via start_cpu(). > > */ > > ENTRY(start_cpu0) > > - movq initial_stack(%rip),%rsp > > - movq initial_code(%rip),%rax > > - pushq $0 # fake return address to stop unwinder > > - pushq $__KERNEL_CS # set correct cs > > - pushq %rax # target address in negative space > > - lretq > > + movq initial_stack(%rip), %rsp > > + jmp start_cpu > > ENDPROC(start_cpu0) > > #endif > > > > I have small suggestion here. To me jumping from start_cpu0 into the > middle of secondary_startup_64 just seems strange. May be we can > define separate ENTRY and ENDPROC pair for start_cpu and jump there > from start_cpu0 and also from secondary_startup_64. Yeah, that might be better. But then again, it would also be strange to add a jump at the end of secondary_startup_64, when it could instead just fall through. Maybe I should do as you suggest, but instead of the jump, add a comment that it falls through to start_cpu()? -- Josh