x86/head_64.S: Rename start_cpu()

From: Borislav Petkov <[email protected]>

... so that callees don't have to convert it and can use it directly. Simplifies C code a bit. Cleanup comments and formatting in the vicinity, while at it.

Also, document what phys_base really is.

No functionality change.

Signed-off-by Borislav Petkov <[email protected]>

---
 arch/x86/kernel/head64.c  |  8 ++++----
 arch/x86/kernel/head_64.S | 10 +++++++---
 2 files changed, 11 insertions(+), 7 deletions(-)

arch/x86/kernel/head64.c +4 -4

index 54a2372f5dbb..17ee20a9b4e4 100644
@@ -118,7 +118,7 @@ static unsigned long get_cmd_line_ptr(void)
 
 static void __init copy_bootdata(char *real_mode_data)
 {
-	char * command_line;
+	char *command_line;
 	unsigned long cmd_line_ptr;
 
 	memcpy(&boot_params, real_mode_data, sizeof boot_params);

@@ -130,7 +130,7 @@ static void __init copy_bootdata(char *real_mode_data)
 	}
 }
 
-asmlinkage __visible void __init x86_64_start_kernel(char * real_mode_data)
+asmlinkage __visible void __init x86_64_start_kernel(char *real_mode_data)
 {
 	int i;
 

@@ -163,7 +163,7 @@ asmlinkage __visible void __init x86_64_start_kernel(char * real_mode_data)
 		set_intr_gate(i, early_idt_handler_array[i]);
 	load_idt((const struct desc_ptr *)&idt_descr);
 
-	copy_bootdata(__va(real_mode_data));
+	copy_bootdata(real_mode_data);
 
 	/*
 	 * Load microcode early on BSP.

@@ -180,7 +180,7 @@ void __init x86_64_start_reservations(char *real_mode_data)
 {
 	/* version is always not zero if it is copied */
 	if (!boot_params.hdr.version)
-		copy_bootdata(__va(real_mode_data));
+		copy_bootdata(real_mode_data);
 
 	x86_early_init_platform_quirks();
 

arch/x86/kernel/head_64.S +0 -0

index ac9d327d2e42..506de36293bc 100644
@@ -266,9 +266,12 @@ ENTRY(secondary_startup_64)
 	movl	initial_gs+4(%rip),%edx
 	wrmsr

The updated comments and other details are fine, but I'm not sure about the __va()
change: the patch essentially open codes __va() in assembly - which would make any changes to __va() [for whatever reason] more difficult, right?

Right now we don't seem to have a single such line of assembly, so changes to __va() can be done in C alone.

From: Borislav Petkov <[email protected]>

It doesn't really start a CPU but does a far jump to C code. So call it that. Eliminate the unconditional JMP to it from secondary_startup_64() but make the jump to C code piece part of secondary_startup_64() instead.

Also, it doesn't need to be a global symbol either so make it a local label. One less needlessly global symbol in the symbol table.

No functionality change.

Signed-off-by Borislav Petkov <[email protected]>

---
 arch/x86/kernel/head_64.S | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

arch/x86/kernel/head_64.S +2 -4

index b467b14b03eb..ac9d327d2e42 100644
@@ -269,10 +269,8 @@ ENTRY(secondary_startup_64)
 	/* rsi is pointer to real mode structure with interesting info.
 	   pass it to C */
 	movq	%rsi, %rdi
-	jmp	start_cpu
-ENDPROC(secondary_startup_64)
 
-ENTRY(start_cpu)
+.Ljump_to_C_code:
 	/*
 	 * 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

@@ -305,7 +303,7 @@ ENTRY(start_cpu)
 	pushq	%rax		# target address in negative space
 	lretq
 .Lafter_lret:
-ENDPROC(start_cpu)
+ENDPROC(secondary_startup_64)
 
 #include "verify_cpu.S"
 

@@ -313,11 +311,11 @@ ENDPROC(start_cpu)
 /*
  * Boot CPU0 entry point. It's called from play_dead(). Everything has been set

The local labels syntax is silly, I always end up looking twice to make sense of 'Ljump' or 'Lwhatever' ;-)

We cannot do anything about that - but we can name our symbols to work it around. But the price is the extra underscore in the symbol name...

Quoted 5 lines · Ingo Molnar

The local labels syntax is silly, I always end up looking twice to make sense of 'Ljump' or 'Lwhatever' ;-)

We cannot do anything about that - but we can name our symbols to work it around. But the price is the extra underscore in the symbol name...

Sure, but other labels in this file don't have the preceding "_".

Perhaps we should agree on a convention for the local labels naming in our asm and adhere to it...