All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 3/5] x86, AMD: cleanup: merge common code in early microcode loading
@ 2013-07-23 21:00 Torsten Kaiser
  2013-07-24 13:32 ` Borislav Petkov
  0 siblings, 1 reply; 10+ messages in thread
From: Torsten Kaiser @ 2013-07-23 21:00 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Borislav Petkov,
	Jacob Shin, Johannes Hirte, linux-kernel

Extract common checks and initialisations from load_ucode_ap() and
save_microcode_in_initrd_amd() to load_microcode_amd_early().
load_ucode_ap() gets a quick exit for !cpu, because for the BSP there is
already a different function dealing with its update.

The original code already didn't anything, because without load_microcode_amd()
getting called apply_microcode_amd() could not do anything.

Signed-off-by: Torsten Kaiser <just.for.lkml@googlemail.com>

--- a/arch/x86/kernel/microcode_amd_early.c	2013-07-22 06:22:32.000000000 +0200
+++ b/arch/x86/kernel/microcode_amd_early.c	2013-07-23 20:00:04.889508712 +0200
@@ -196,6 +196,23 @@ void __init load_ucode_amd_bsp(void)
 	apply_ucode_in_initrd(cd.data, cd.size);
 }
 
+static int load_microcode_amd_early(void)
+{
+	enum ucode_state ret;
+	void *ucode;
+
+	if (ucode_loaded || !ucode_size || !initrd_start)
+		return 0;
+
+	ucode = (void *)(initrd_start + ucode_offset);
+	ret = load_microcode_amd(0, ucode, ucode_size);
+	if (ret != UCODE_OK)
+		return -EINVAL;
+
+	ucode_loaded = true;
+	return 0;
+}
+
 #ifdef CONFIG_X86_32
 u8 amd_bsp_mpb[MPB_MAX_SIZE];
 
@@ -258,17 +275,13 @@ void load_ucode_amd_ap(void)
 
 	collect_cpu_info_amd_early(&cpu_data(cpu), ucode_cpu_info + cpu);
 
-	if (cpu && !ucode_loaded) {
-		void *ucode;
-
-		if (!ucode_size || !initrd_start)
-			return;
+	/* BSP via load_ucode_amd_bsp() */
+	if (!cpu)
+		return;
 
-		ucode = (void *)(initrd_start + ucode_offset);
-		if (load_microcode_amd(0, ucode, ucode_size) != UCODE_OK)
-			return;
-		ucode_loaded = true;
-	}
+	load_microcode_amd_early();
+	if (!ucode_loaded)
+		return;
 
 	apply_microcode_amd(cpu);
 }
@@ -276,8 +289,6 @@ void load_ucode_amd_ap(void)
 
 int __init save_microcode_in_initrd_amd(void)
 {
-	enum ucode_state ret;
-	void *ucode;
 #ifdef CONFIG_X86_32
 	unsigned int bsp = boot_cpu_data.cpu_index;
 	struct ucode_cpu_info *uci = ucode_cpu_info + bsp;
@@ -289,14 +300,5 @@ int __init save_microcode_in_initrd_amd(
 		pr_info("microcode: updated early to new patch_level=0x%08x\n",
 			ucode_new_rev);
 
-	if (ucode_loaded || !ucode_size || !initrd_start)
-		return 0;
-
-	ucode = (void *)(initrd_start + ucode_offset);
-	ret = load_microcode_amd(0, ucode, ucode_size);
-	if (ret != UCODE_OK)
-		return -EINVAL;
-
-	ucode_loaded = true;
-	return 0;
+	return load_microcode_amd_early();
 }

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 3/5] x86, AMD: cleanup: merge common code in early microcode loading
  2013-07-23 21:00 [PATCH 3/5] x86, AMD: cleanup: merge common code in early microcode loading Torsten Kaiser
@ 2013-07-24 13:32 ` Borislav Petkov
  2013-08-07 22:46   ` Yu, Fenghua
  2013-08-07 23:34   ` Yu, Fenghua
  0 siblings, 2 replies; 10+ messages in thread
From: Borislav Petkov @ 2013-07-24 13:32 UTC (permalink / raw)
  To: Torsten Kaiser, Fenghua Yu
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Jacob Shin,
	Johannes Hirte, linux-kernel

On Tue, Jul 23, 2013 at 11:00:26PM +0200, Torsten Kaiser wrote:
> Extract common checks and initialisations from load_ucode_ap() and
> save_microcode_in_initrd_amd() to load_microcode_amd_early().
> load_ucode_ap() gets a quick exit for !cpu, because for the BSP there is
> already a different function dealing with its update.
> 
> The original code already didn't anything, because without load_microcode_amd()
> getting called apply_microcode_amd() could not do anything.
> 
> Signed-off-by: Torsten Kaiser <just.for.lkml@googlemail.com>
> 
> --- a/arch/x86/kernel/microcode_amd_early.c	2013-07-22 06:22:32.000000000 +0200
> +++ b/arch/x86/kernel/microcode_amd_early.c	2013-07-23 20:00:04.889508712 +0200
> @@ -196,6 +196,23 @@ void __init load_ucode_amd_bsp(void)
>  	apply_ucode_in_initrd(cd.data, cd.size);
>  }
>  
> +static int load_microcode_amd_early(void)
> +{
> +	enum ucode_state ret;
> +	void *ucode;
> +
> +	if (ucode_loaded || !ucode_size || !initrd_start)
> +		return 0;
> +
> +	ucode = (void *)(initrd_start + ucode_offset);
> +	ret = load_microcode_amd(0, ucode, ucode_size);
> +	if (ret != UCODE_OK)
> +		return -EINVAL;
> +
> +	ucode_loaded = true;
> +	return 0;
> +}
> +
>  #ifdef CONFIG_X86_32
>  u8 amd_bsp_mpb[MPB_MAX_SIZE];
>  
> @@ -258,17 +275,13 @@ void load_ucode_amd_ap(void)
>  
>  	collect_cpu_info_amd_early(&cpu_data(cpu), ucode_cpu_info + cpu);
>  
> -	if (cpu && !ucode_loaded) {
> -		void *ucode;
> -
> -		if (!ucode_size || !initrd_start)
> -			return;
> +	/* BSP via load_ucode_amd_bsp() */
> +	if (!cpu)
> +		return;

Ok, this is really misleading. Fenghua, what's the reason for calling
load_ucode_ap() on the BSP too?

We have on the one hand:

x86_64_start_kernel
|->load_ucode_bsp

and on the other:

x86_64_start_kernel
|-> x86_64_start_reservations
    |-> start_kernel
        |-> trap_init
	    |-> cpu_init
	        |-> load_ucode_ap()

so we attempt to load the ucode twice on the BSP.

IMO, we should do this in cpu_init:

	if (cpu)
		load_ucode_ap();

no?

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

^ permalink raw reply	[flat|nested] 10+ messages in thread

* RE: [PATCH 3/5] x86, AMD: cleanup: merge common code in early microcode loading
  2013-07-24 13:32 ` Borislav Petkov
@ 2013-08-07 22:46   ` Yu, Fenghua
  2013-08-07 23:34   ` Yu, Fenghua
  1 sibling, 0 replies; 10+ messages in thread
From: Yu, Fenghua @ 2013-08-07 22:46 UTC (permalink / raw)
  To: Borislav Petkov, Torsten Kaiser
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Jacob Shin,
	Johannes Hirte, linux-kernel

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2703 bytes --]

> From: Borislav Petkov [mailto:bp@alien8.de]
> Sent: Wednesday, July 24, 2013 6:33 AM
> On Tue, Jul 23, 2013 at 11:00:26PM +0200, Torsten Kaiser wrote:
> > Extract common checks and initialisations from load_ucode_ap() and
> > save_microcode_in_initrd_amd() to load_microcode_amd_early().
> > load_ucode_ap() gets a quick exit for !cpu, because for the BSP there
> is
> > already a different function dealing with its update.
> >
> > The original code already didn't anything, because without
> load_microcode_amd()
> > getting called apply_microcode_amd() could not do anything.
> >
> > Signed-off-by: Torsten Kaiser <just.for.lkml@googlemail.com>
> >
> > --- a/arch/x86/kernel/microcode_amd_early.c	2013-07-22
> 06:22:32.000000000 +0200
> > +++ b/arch/x86/kernel/microcode_amd_early.c	2013-07-23
> 20:00:04.889508712 +0200
> > @@ -196,6 +196,23 @@ void __init load_ucode_amd_bsp(void)
> >  	apply_ucode_in_initrd(cd.data, cd.size);
> >  }
> >
> > +static int load_microcode_amd_early(void)
> > +{
> > +	enum ucode_state ret;
> > +	void *ucode;
> > +
> > +	if (ucode_loaded || !ucode_size || !initrd_start)
> > +		return 0;
> > +
> > +	ucode = (void *)(initrd_start + ucode_offset);
> > +	ret = load_microcode_amd(0, ucode, ucode_size);
> > +	if (ret != UCODE_OK)
> > +		return -EINVAL;
> > +
> > +	ucode_loaded = true;
> > +	return 0;
> > +}
> > +
> >  #ifdef CONFIG_X86_32
> >  u8 amd_bsp_mpb[MPB_MAX_SIZE];
> >
> > @@ -258,17 +275,13 @@ void load_ucode_amd_ap(void)
> >
> >  	collect_cpu_info_amd_early(&cpu_data(cpu), ucode_cpu_info + cpu);
> >
> > -	if (cpu && !ucode_loaded) {
> > -		void *ucode;
> > -
> > -		if (!ucode_size || !initrd_start)
> > -			return;
> > +	/* BSP via load_ucode_amd_bsp() */
> > +	if (!cpu)
> > +		return;
> 
> Ok, this is really misleading. Fenghua, what's the reason for calling
> load_ucode_ap() on the BSP too?
> 
> We have on the one hand:
> 
> x86_64_start_kernel
> |->load_ucode_bsp
> 
> and on the other:
> 
> x86_64_start_kernel
> |-> x86_64_start_reservations
>     |-> start_kernel
>         |-> trap_init
> 	    |-> cpu_init
> 	        |-> load_ucode_ap()
> 
> so we attempt to load the ucode twice on the BSP.
> 

You are right. Though the second time loading attempt will not find a valid/newer ucode patch to update. So this won't cause a real/serious problem. But we had better to fix this anyway.

> IMO, we should do this in cpu_init:
> 
> 	if (cpu)
> 		load_ucode_ap();
> 
> no?

This check won't work when CPU0 is hot added. So we need to find a better way to fix this.

Thanks.

-Fenghua
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 10+ messages in thread

* RE: [PATCH 3/5] x86, AMD: cleanup: merge common code in early microcode loading
  2013-07-24 13:32 ` Borislav Petkov
  2013-08-07 22:46   ` Yu, Fenghua
@ 2013-08-07 23:34   ` Yu, Fenghua
  2013-08-08  2:22     ` H. Peter Anvin
  2013-08-08 17:49     ` Borislav Petkov
  1 sibling, 2 replies; 10+ messages in thread
From: Yu, Fenghua @ 2013-08-07 23:34 UTC (permalink / raw)
  To: Borislav Petkov, Torsten Kaiser
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Jacob Shin,
	Johannes Hirte, linux-kernel

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 3121 bytes --]

> From: Yu, Fenghua
> Sent: Wednesday, August 07, 2013 3:46 PM
> 
> > From: Borislav Petkov [mailto:bp@alien8.de]
> > Sent: Wednesday, July 24, 2013 6:33 AM
> > On Tue, Jul 23, 2013 at 11:00:26PM +0200, Torsten Kaiser wrote:
> > > Extract common checks and initialisations from load_ucode_ap() and
> > > save_microcode_in_initrd_amd() to load_microcode_amd_early().
> > > load_ucode_ap() gets a quick exit for !cpu, because for the BSP
> there
> > is
> > > already a different function dealing with its update.
> > >
> > > The original code already didn't anything, because without
> > load_microcode_amd()
> > > getting called apply_microcode_amd() could not do anything.
> > >
> > > Signed-off-by: Torsten Kaiser <just.for.lkml@googlemail.com>
> > >
> > > --- a/arch/x86/kernel/microcode_amd_early.c	2013-07-22
> > 06:22:32.000000000 +0200
> > > +++ b/arch/x86/kernel/microcode_amd_early.c	2013-07-23
> > 20:00:04.889508712 +0200
> > > @@ -196,6 +196,23 @@ void __init load_ucode_amd_bsp(void)
> > >  	apply_ucode_in_initrd(cd.data, cd.size);
> > >  }
> > >
> > > +static int load_microcode_amd_early(void)
> > > +{
> > > +	enum ucode_state ret;
> > > +	void *ucode;
> > > +
> > > +	if (ucode_loaded || !ucode_size || !initrd_start)
> > > +		return 0;
> > > +
> > > +	ucode = (void *)(initrd_start + ucode_offset);
> > > +	ret = load_microcode_amd(0, ucode, ucode_size);
> > > +	if (ret != UCODE_OK)
> > > +		return -EINVAL;
> > > +
> > > +	ucode_loaded = true;
> > > +	return 0;
> > > +}
> > > +
> > >  #ifdef CONFIG_X86_32
> > >  u8 amd_bsp_mpb[MPB_MAX_SIZE];
> > >
> > > @@ -258,17 +275,13 @@ void load_ucode_amd_ap(void)
> > >
> > >  	collect_cpu_info_amd_early(&cpu_data(cpu), ucode_cpu_info + cpu);
> > >
> > > -	if (cpu && !ucode_loaded) {
> > > -		void *ucode;
> > > -
> > > -		if (!ucode_size || !initrd_start)
> > > -			return;
> > > +	/* BSP via load_ucode_amd_bsp() */
> > > +	if (!cpu)
> > > +		return;
> >
> > Ok, this is really misleading. Fenghua, what's the reason for calling
> > load_ucode_ap() on the BSP too?
> >
> > We have on the one hand:
> >
> > x86_64_start_kernel
> > |->load_ucode_bsp
> >
> > and on the other:
> >
> > x86_64_start_kernel
> > |-> x86_64_start_reservations
> >     |-> start_kernel
> >         |-> trap_init
> > 	    |-> cpu_init
> > 	        |-> load_ucode_ap()
> >
> > so we attempt to load the ucode twice on the BSP.
> >
> 
> You are right. Though the second time loading attempt will not find a
> valid/newer ucode patch to update. So this won't cause a real/serious
> problem. But we had better to fix this anyway.
> 
> > IMO, we should do this in cpu_init:
> >
> > 	if (cpu)
> > 		load_ucode_ap();
> >
> > no?
> 
> This check won't work when CPU0 is hot added. So we need to find a
> better way to fix this.
> 

Maybe need to change the check as follows to take care of CPU0 hot add case?

if ((cpu && system_state == SYSTEM_BOOTING) || (system_state == SYSTEM_RUNNING))
	load_ucode_ap();

Thanks.

-Fenghua
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 10+ messages in thread

* RE: [PATCH 3/5] x86, AMD: cleanup: merge common code in early microcode loading
  2013-08-07 23:34   ` Yu, Fenghua
@ 2013-08-08  2:22     ` H. Peter Anvin
  2013-08-08 10:02       ` Borislav Petkov
  2013-08-08 17:49     ` Borislav Petkov
  1 sibling, 1 reply; 10+ messages in thread
From: H. Peter Anvin @ 2013-08-08  2:22 UTC (permalink / raw)
  To: Yu, Fenghua, Borislav Petkov, Torsten Kaiser
  Cc: Thomas Gleixner, Ingo Molnar, Jacob Shin, Johannes Hirte, linux-kernel

How much does this matter?

"Yu, Fenghua" <fenghua.yu@intel.com> wrote:
>> From: Yu, Fenghua
>> Sent: Wednesday, August 07, 2013 3:46 PM
>> 
>> > From: Borislav Petkov [mailto:bp@alien8.de]
>> > Sent: Wednesday, July 24, 2013 6:33 AM
>> > On Tue, Jul 23, 2013 at 11:00:26PM +0200, Torsten Kaiser wrote:
>> > > Extract common checks and initialisations from load_ucode_ap()
>and
>> > > save_microcode_in_initrd_amd() to load_microcode_amd_early().
>> > > load_ucode_ap() gets a quick exit for !cpu, because for the BSP
>> there
>> > is
>> > > already a different function dealing with its update.
>> > >
>> > > The original code already didn't anything, because without
>> > load_microcode_amd()
>> > > getting called apply_microcode_amd() could not do anything.
>> > >
>> > > Signed-off-by: Torsten Kaiser <just.for.lkml@googlemail.com>
>> > >
>> > > --- a/arch/x86/kernel/microcode_amd_early.c	2013-07-22
>> > 06:22:32.000000000 +0200
>> > > +++ b/arch/x86/kernel/microcode_amd_early.c	2013-07-23
>> > 20:00:04.889508712 +0200
>> > > @@ -196,6 +196,23 @@ void __init load_ucode_amd_bsp(void)
>> > >  	apply_ucode_in_initrd(cd.data, cd.size);
>> > >  }
>> > >
>> > > +static int load_microcode_amd_early(void)
>> > > +{
>> > > +	enum ucode_state ret;
>> > > +	void *ucode;
>> > > +
>> > > +	if (ucode_loaded || !ucode_size || !initrd_start)
>> > > +		return 0;
>> > > +
>> > > +	ucode = (void *)(initrd_start + ucode_offset);
>> > > +	ret = load_microcode_amd(0, ucode, ucode_size);
>> > > +	if (ret != UCODE_OK)
>> > > +		return -EINVAL;
>> > > +
>> > > +	ucode_loaded = true;
>> > > +	return 0;
>> > > +}
>> > > +
>> > >  #ifdef CONFIG_X86_32
>> > >  u8 amd_bsp_mpb[MPB_MAX_SIZE];
>> > >
>> > > @@ -258,17 +275,13 @@ void load_ucode_amd_ap(void)
>> > >
>> > >  	collect_cpu_info_amd_early(&cpu_data(cpu), ucode_cpu_info +
>cpu);
>> > >
>> > > -	if (cpu && !ucode_loaded) {
>> > > -		void *ucode;
>> > > -
>> > > -		if (!ucode_size || !initrd_start)
>> > > -			return;
>> > > +	/* BSP via load_ucode_amd_bsp() */
>> > > +	if (!cpu)
>> > > +		return;
>> >
>> > Ok, this is really misleading. Fenghua, what's the reason for
>calling
>> > load_ucode_ap() on the BSP too?
>> >
>> > We have on the one hand:
>> >
>> > x86_64_start_kernel
>> > |->load_ucode_bsp
>> >
>> > and on the other:
>> >
>> > x86_64_start_kernel
>> > |-> x86_64_start_reservations
>> >     |-> start_kernel
>> >         |-> trap_init
>> > 	    |-> cpu_init
>> > 	        |-> load_ucode_ap()
>> >
>> > so we attempt to load the ucode twice on the BSP.
>> >
>> 
>> You are right. Though the second time loading attempt will not find a
>> valid/newer ucode patch to update. So this won't cause a real/serious
>> problem. But we had better to fix this anyway.
>> 
>> > IMO, we should do this in cpu_init:
>> >
>> > 	if (cpu)
>> > 		load_ucode_ap();
>> >
>> > no?
>> 
>> This check won't work when CPU0 is hot added. So we need to find a
>> better way to fix this.
>> 
>
>Maybe need to change the check as follows to take care of CPU0 hot add
>case?
>
>if ((cpu && system_state == SYSTEM_BOOTING) || (system_state ==
>SYSTEM_RUNNING))
>	load_ucode_ap();
>
>Thanks.
>
>-Fenghua

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 3/5] x86, AMD: cleanup: merge common code in early microcode loading
  2013-08-08  2:22     ` H. Peter Anvin
@ 2013-08-08 10:02       ` Borislav Petkov
  2013-08-08 18:28         ` Borislav Petkov
  0 siblings, 1 reply; 10+ messages in thread
From: Borislav Petkov @ 2013-08-08 10:02 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Yu, Fenghua, Torsten Kaiser, Thomas Gleixner, Ingo Molnar,
	Jacob Shin, Johannes Hirte, linux-kernel

On Wed, Aug 07, 2013 at 07:22:39PM -0700, H. Peter Anvin wrote:
> How much does this matter?

I know what you're asking :-)

And no, it doesn't really matter as we fail in the patch version check
so maybe only a comment will suffice here so that people don't get
confused.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 3/5] x86, AMD: cleanup: merge common code in early microcode loading
  2013-08-07 23:34   ` Yu, Fenghua
  2013-08-08  2:22     ` H. Peter Anvin
@ 2013-08-08 17:49     ` Borislav Petkov
  2013-08-09 18:38       ` Yu, Fenghua
  1 sibling, 1 reply; 10+ messages in thread
From: Borislav Petkov @ 2013-08-08 17:49 UTC (permalink / raw)
  To: Yu, Fenghua
  Cc: Torsten Kaiser, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Jacob Shin, Johannes Hirte, linux-kernel

On Wed, Aug 07, 2013 at 11:34:01PM +0000, Yu, Fenghua wrote:
> > This check won't work when CPU0 is hot added. So we need to find a
> > better way to fix this.
> > 
> 
> Maybe need to change the check as follows to take care of CPU0 hot add case?
> 
> if ((cpu && system_state == SYSTEM_BOOTING) || (system_state == SYSTEM_RUNNING))
> 	load_ucode_ap();

Ok, just for my own understanding - I haven't played with cpu hotadd yet
so when you do this, is the hot-added socket containing the BSP not cpu
0 anymore?

Or when you hot-remove the socket containing the BSP, another AP becomes
the BSP and preserves its old number?

Thanks.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 3/5] x86, AMD: cleanup: merge common code in early microcode loading
  2013-08-08 10:02       ` Borislav Petkov
@ 2013-08-08 18:28         ` Borislav Petkov
  2013-08-09 18:44           ` Yu, Fenghua
  0 siblings, 1 reply; 10+ messages in thread
From: Borislav Petkov @ 2013-08-08 18:28 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Yu, Fenghua, Torsten Kaiser, Thomas Gleixner, Ingo Molnar,
	Jacob Shin, Johannes Hirte, linux-kernel

On Thu, Aug 08, 2013 at 12:02:38PM +0200, Borislav Petkov wrote:
> On Wed, Aug 07, 2013 at 07:22:39PM -0700, H. Peter Anvin wrote:
> > How much does this matter?
> 
> I know what you're asking :-)
> 
> And no, it doesn't really matter as we fail in the patch version check
> so maybe only a comment will suffice here so that people don't get
> confused.

IOW, something like that:

---
From: Borislav Petkov <bp@suse.de>
Date: Thu, 8 Aug 2013 20:26:24 +0200
Subject: [PATCH] x86, microcode: Clarify loading on the AP

Hold it down why we're calling the AP microcode loading routine on the
BSP too, for future reference.

Signed-off-by: Borislav Petkov <bp@suse.de>
---
 arch/x86/kernel/cpu/common.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 25eb2747b063..58d37a27d317 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1226,8 +1226,12 @@ void cpu_init(void)
 	int i;
 
 	/*
-	 * Load microcode on this cpu if a valid microcode is available.
-	 * This is early microcode loading procedure.
+	 * Load microcode on this cpu if a valid microcode is available. This
+	 * is early microcode loading procedure. We execute this on the BSP too
+	 * but since a microcode has been potentially already applied on the
+	 * BSP, we will return prematurely here. It is easier to simply call it
+	 * again than filtering all the possible cases when we're not running
+	 * on the BSP.
 	 */
 	load_ucode_ap();
 
-- 
1.8.3

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

^ permalink raw reply related	[flat|nested] 10+ messages in thread

* RE: [PATCH 3/5] x86, AMD: cleanup: merge common code in early microcode loading
  2013-08-08 17:49     ` Borislav Petkov
@ 2013-08-09 18:38       ` Yu, Fenghua
  0 siblings, 0 replies; 10+ messages in thread
From: Yu, Fenghua @ 2013-08-09 18:38 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Torsten Kaiser, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Jacob Shin, Johannes Hirte, linux-kernel

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1150 bytes --]

> From: Borislav Petkov [mailto:bp@alien8.de]
> Sent: Thursday, August 08, 2013 10:49 AM
> On Wed, Aug 07, 2013 at 11:34:01PM +0000, Yu, Fenghua wrote:
> > > This check won't work when CPU0 is hot added. So we need to find a
> > > better way to fix this.
> > >
> >
> > Maybe need to change the check as follows to take care of CPU0 hot
> add case?
> >
> > if ((cpu && system_state == SYSTEM_BOOTING) || (system_state ==
> SYSTEM_RUNNING))
> > 	load_ucode_ap();
> 
> Ok, just for my own understanding - I haven't played with cpu hotadd
> yet
> so when you do this, is the hot-added socket containing the BSP not cpu
> 0 anymore?
> 
> Or when you hot-remove the socket containing the BSP, another AP
> becomes
> the BSP and preserves its old number?

When BSP is logically hot removed/offlined, there is no BSP any more in Linux, i.e. cpu0 is not in online mask. CPU0 can be logically hot added back again.

Currently kernel doesn't support physically hot remove CPU0 yet.

Thanks.

-Fenghua
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 10+ messages in thread

* RE: [PATCH 3/5] x86, AMD: cleanup: merge common code in early microcode loading
  2013-08-08 18:28         ` Borislav Petkov
@ 2013-08-09 18:44           ` Yu, Fenghua
  0 siblings, 0 replies; 10+ messages in thread
From: Yu, Fenghua @ 2013-08-09 18:44 UTC (permalink / raw)
  To: Borislav Petkov, H. Peter Anvin
  Cc: Torsten Kaiser, Thomas Gleixner, Ingo Molnar, Jacob Shin,
	Johannes Hirte, linux-kernel

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2047 bytes --]

> From: Borislav Petkov [mailto:bp@alien8.de]
> Sent: Thursday, August 08, 2013 11:29 AM

> On Thu, Aug 08, 2013 at 12:02:38PM +0200, Borislav Petkov wrote:
> > On Wed, Aug 07, 2013 at 07:22:39PM -0700, H. Peter Anvin wrote:
> > > How much does this matter?
> >
> > I know what you're asking :-)
> >
> > And no, it doesn't really matter as we fail in the patch version
> check
> > so maybe only a comment will suffice here so that people don't get
> > confused.
> 
> IOW, something like that:
> 
> ---
> From: Borislav Petkov <bp@suse.de>
> Date: Thu, 8 Aug 2013 20:26:24 +0200
> Subject: [PATCH] x86, microcode: Clarify loading on the AP
> 
> Hold it down why we're calling the AP microcode loading routine on the
> BSP too, for future reference.
> 
> Signed-off-by: Borislav Petkov <bp@suse.de>
> ---
>  arch/x86/kernel/cpu/common.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/common.c
> b/arch/x86/kernel/cpu/common.c
> index 25eb2747b063..58d37a27d317 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -1226,8 +1226,12 @@ void cpu_init(void)
>  	int i;
> 
>  	/*
> -	 * Load microcode on this cpu if a valid microcode is available.
> -	 * This is early microcode loading procedure.
> +	 * Load microcode on this cpu if a valid microcode is available.
> This
> +	 * is early microcode loading procedure. We execute this on the
> BSP too
> +	 * but since a microcode has been potentially already applied on
> the
> +	 * BSP, we will return prematurely here. It is easier to simply
> call it
> +	 * again than filtering all the possible cases when we're not
> running
> +	 * on the BSP.
>  	 */
>  	load_ucode_ap();

Load_ucode_ap() running on BSP during boot time wastes short time on scanning ucode blob. But the time should be very short. 

Reviewed-by: Fenghua Yu <fenghua.yu@intel.com>

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2013-08-09 18:44 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-07-23 21:00 [PATCH 3/5] x86, AMD: cleanup: merge common code in early microcode loading Torsten Kaiser
2013-07-24 13:32 ` Borislav Petkov
2013-08-07 22:46   ` Yu, Fenghua
2013-08-07 23:34   ` Yu, Fenghua
2013-08-08  2:22     ` H. Peter Anvin
2013-08-08 10:02       ` Borislav Petkov
2013-08-08 18:28         ` Borislav Petkov
2013-08-09 18:44           ` Yu, Fenghua
2013-08-08 17:49     ` Borislav Petkov
2013-08-09 18:38       ` Yu, Fenghua

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.