[GIT PULL] x86/microcode for v3.9-rc1

[GIT PULL] x86/microcode for v3.9-rc1

[H. Peter Anvin]

Hi Linus,

This patchset lets us update the CPU microcode very, very early in
initialization if the BIOS fails to do so (never happens, right?)
This is handy for dealing with things like the Atom erratum where we
have to run without PSE because microcode loading happens too late.

As I mentioned in the x86/mm push request it depends on that
infrastructure but it is otherwise a standalone feature.

----------------------------------------------------------------

The following changes since commit ac2cbab21f318e19bc176a7f38a120cec835220f:

  x86: Don't panic if can not alloc buffer for swiotlb (2013-01-29 19:36:53 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/microcode

for you to fetch changes up to da76f64e7eb28b718501d15c1b79af560b7ca4ea:

  x86/Kconfig: Make early microcode loading a configuration feature (2013-01-31 13:20:42 -0800)

----------------------------------------------------------------

Fenghua Yu (12):
      x86, doc: Documentation for early microcode loading
      x86/microcode_intel.h: Define functions and macros for early loading ucode
      x86/common.c: Make have_cpuid_p() a global function
      x86/common.c: load ucode in 64 bit or show loading ucode info in 32 bit on AP
      x86/microcode_core_early.c: Define interfaces for early loading ucode
      x86/microcode_intel_lib.c: Early update ucode on Intel's CPU
      x86/tlbflush.h: Define __native_flush_tlb_global_irq_disabled()
      x86/microcode_intel_early.c: Early update ucode on Intel's CPU
      x86/head_32.S: Early update ucode in 32-bit
      x86/head64.c: Early update ucode in 64-bit
      x86/mm/init.c: Copy ucode from initrd image to kernel memory
      x86/Kconfig: Make early microcode loading a configuration feature

 Documentation/x86/early-microcode.txt   |  43 ++
 arch/x86/Kconfig                        |  18 +
 arch/x86/include/asm/microcode.h        |  14 +
 arch/x86/include/asm/microcode_intel.h  |  85 ++++
 arch/x86/include/asm/processor.h        |   8 +
 arch/x86/include/asm/tlbflush.h         |  18 +-
 arch/x86/kernel/Makefile                |   3 +
 arch/x86/kernel/cpu/common.c            |  17 +-
 arch/x86/kernel/head64.c                |   6 +
 arch/x86/kernel/head_32.S               |  11 +
 arch/x86/kernel/microcode_core.c        |   7 +-
 arch/x86/kernel/microcode_core_early.c  |  76 +++
 arch/x86/kernel/microcode_intel.c       | 198 ++------
 arch/x86/kernel/microcode_intel_early.c | 796 ++++++++++++++++++++++++++++++++
 arch/x86/kernel/microcode_intel_lib.c   | 174 +++++++
 arch/x86/mm/init.c                      |  10 +
 16 files changed, 1301 insertions(+), 183 deletions(-)

[full diff omitted due to length]

Re: [GIT PULL] x86/microcode for v3.9-rc1

[Borislav Petkov]

On Thu, Feb 21, 2013 at 08:56:36PM -0800, H. Peter Anvin wrote:
> Hi Linus,
> 
> This patchset lets us update the CPU microcode very, very early in
> initialization if the BIOS fails to do so (never happens, right?)
> This is handy for dealing with things like the Atom erratum where we
> have to run without PSE because microcode loading happens too late.
> 
> As I mentioned in the x86/mm push request it depends on that
> infrastructure but it is otherwise a standalone feature.
> 
> ----------------------------------------------------------------
> 
> The following changes since commit ac2cbab21f318e19bc176a7f38a120cec835220f:
> 
>   x86: Don't panic if can not alloc buffer for swiotlb (2013-01-29 19:36:53 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/microcode
> 
> for you to fetch changes up to da76f64e7eb28b718501d15c1b79af560b7ca4ea:
> 
>   x86/Kconfig: Make early microcode loading a configuration feature (2013-01-31 13:20:42 -0800)
> 
> ----------------------------------------------------------------
> 
> Fenghua Yu (12):
>       x86, doc: Documentation for early microcode loading
>       x86/microcode_intel.h: Define functions and macros for early loading ucode
>       x86/common.c: Make have_cpuid_p() a global function
>       x86/common.c: load ucode in 64 bit or show loading ucode info in 32 bit on AP
>       x86/microcode_core_early.c: Define interfaces for early loading ucode
>       x86/microcode_intel_lib.c: Early update ucode on Intel's CPU
>       x86/tlbflush.h: Define __native_flush_tlb_global_irq_disabled()
>       x86/microcode_intel_early.c: Early update ucode on Intel's CPU
>       x86/head_32.S: Early update ucode in 32-bit
>       x86/head64.c: Early update ucode in 64-bit
>       x86/mm/init.c: Copy ucode from initrd image to kernel memory
>       x86/Kconfig: Make early microcode loading a configuration feature

Some strange build warnings I get here:

arch/x86/kernel/microcode_intel_early.c: In function `get_matching_model_microcode.isra.3.constprop.9':
arch/x86/kernel/microcode_intel_early.c:366:1: warning: the frame size of 1072 bytes is larger than 1024 bytes [-Wframe-larger-than=]
arch/x86/kernel/microcode_intel_early.c: In function `save_mc_for_early':
arch/x86/kernel/microcode_intel_early.c:550:1: warning: the frame size of 1040 bytes is larger than 1024 bytes [-Wframe-larger-than=]

What's up?

-- 
Regards/Gruss,
    Boris.

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

Re: [GIT PULL] x86/microcode for v3.9-rc1

[H. Peter Anvin]

On 02/28/2013 03:16 PM, Borislav Petkov wrote:
> 
> Some strange build warnings I get here:
> 
> arch/x86/kernel/microcode_intel_early.c: In function `get_matching_model_microcode.isra.3.constprop.9':
> arch/x86/kernel/microcode_intel_early.c:366:1: warning: the frame size of 1072 bytes is larger than 1024 bytes [-Wframe-larger-than=]
> arch/x86/kernel/microcode_intel_early.c: In function `save_mc_for_early':
> arch/x86/kernel/microcode_intel_early.c:550:1: warning: the frame size of 1040 bytes is larger than 1024 bytes [-Wframe-larger-than=]
> 
> What's up?
> 

gcc is warning that the function is using lots of stack.  In the context
that it is running in this is most likely not a problem given how small
the overrun is, but it might be worthwhile to see if there is anything
which can be moved out to static storage or some other variant.

Static storage is tricky to use in this context since it runs in flat
linear mode (without paging, and therefore without the +3 GB offset) on
32 bits.

	-hpa

RE: [GIT PULL] x86/microcode for v3.9-rc1

[Yu, Fenghua]

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



> -----Original Message-----
> From: H. Peter Anvin [mailto:hpa@zytor.com]
> Sent: Thursday, February 28, 2013 3:23 PM
> To: Borislav Petkov; H. Peter Anvin; Linus Torvalds; Yu, Fenghua; Ingo
> Molnar; Linux Kernel Mailing List; Thomas Gleixner; Yinghai Lu
> Subject: Re: [GIT PULL] x86/microcode for v3.9-rc1
> 
> On 02/28/2013 03:16 PM, Borislav Petkov wrote:
> >
> > Some strange build warnings I get here:
> >
> > arch/x86/kernel/microcode_intel_early.c: In function
> `get_matching_model_microcode.isra.3.constprop.9':
> > arch/x86/kernel/microcode_intel_early.c:366:1: warning: the frame
> size of 1072 bytes is larger than 1024 bytes [-Wframe-larger-than=]
> > arch/x86/kernel/microcode_intel_early.c: In function
> `save_mc_for_early':
> > arch/x86/kernel/microcode_intel_early.c:550:1: warning: the frame
> size of 1040 bytes is larger than 1024 bytes [-Wframe-larger-than=]
> >
> > What's up?
> >
> 
> gcc is warning that the function is using lots of stack.  In the
> context
> that it is running in this is most likely not a problem given how small
> the overrun is, but it might be worthwhile to see if there is anything
> which can be moved out to static storage or some other variant.
> 
> Static storage is tricky to use in this context since it runs in flat
> linear mode (without paging, and therefore without the +3 GB offset) on
> 32 bits.
> 
> 	-hpa

The errors might be related to the arrays defined mc_saved_tmp[MAX_UCODE_COUNT].

Could you send your .config to me so that I can reproduce the issue? I don't see the issue in my build environment and in Fengguang's test environment.

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¥

Re: [GIT PULL] x86/microcode for v3.9-rc1

[Borislav Petkov]

On Thu, Feb 28, 2013 at 11:28:06PM +0000, Yu, Fenghua wrote:
>> gcc is warning that the function is using lots of stack. In the
>> context that it is running in this is most likely not a problem
>> given how small the overrun is, but it might be worthwhile to see if
>> there is anything which can be moved out to static storage or some
>> other variant.
>>
>> Static storage is tricky to use in this context since it runs in
>> flat linear mode (without paging, and therefore without the +3 GB
>> offset) on 32 bits.
>
> The errors might be related to the arrays defined
> mc_saved_tmp[MAX_UCODE_COUNT].
>
> Could you send your .config to me so that I can reproduce the issue?
> I don't see the issue in my build environment and in Fengguang's test
> environment.

Ok, forget it. It was some local .config file corruption which caused
include/generated/autoconf.h and include/config/auto.conf to have a line

CONFIG_FRAME_WARN=1024

which would cause the warnings.

The 1024 ceiling value is also consistent with the warnings complaining
about something being > 1024 bytes.

Default CONFIG_FRAME_WARN on x86_64 is 2048 which explains why those
warnings never trigger on 64-bit.

So, we all can relax ourselves, especially I :-)

Thanks.

-- 
Regards/Gruss,
    Boris.

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

RE: [GIT PULL] x86/microcode for v3.9-rc1

[Yu, Fenghua]

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

> -----Original Message-----
> From: Borislav Petkov [mailto:bp@alien8.de]
> Sent: Thursday, February 28, 2013 3:53 PM
> To: Yu, Fenghua; H. Peter Anvin
> Cc: H. Peter Anvin; Linus Torvalds; Ingo Molnar; Linux Kernel Mailing
> List; Thomas Gleixner; Yinghai Lu
> Subject: Re: [GIT PULL] x86/microcode for v3.9-rc1
> 
> On Thu, Feb 28, 2013 at 11:28:06PM +0000, Yu, Fenghua wrote:
> >> gcc is warning that the function is using lots of stack. In the
> >> context that it is running in this is most likely not a problem
> >> given how small the overrun is, but it might be worthwhile to see if
> >> there is anything which can be moved out to static storage or some
> >> other variant.
> >>
> >> Static storage is tricky to use in this context since it runs in
> >> flat linear mode (without paging, and therefore without the +3 GB
> >> offset) on 32 bits.
> >
> > The errors might be related to the arrays defined
> > mc_saved_tmp[MAX_UCODE_COUNT].
> >
> > Could you send your .config to me so that I can reproduce the issue?
> > I don't see the issue in my build environment and in Fengguang's test
> > environment.
> 
> Ok, forget it. It was some local .config file corruption which caused
> include/generated/autoconf.h and include/config/auto.conf to have a
> line
> 
> CONFIG_FRAME_WARN=1024
> 
> which would cause the warnings.
> 
> The 1024 ceiling value is also consistent with the warnings complaining
> about something being > 1024 bytes.
> 
> Default CONFIG_FRAME_WARN on x86_64 is 2048 which explains why those
> warnings never trigger on 64-bit.
> 
> So, we all can relax ourselves, especially I :-)
> 
> Thanks.
> 
> --
> Regards/Gruss,
>     Boris.
> 
> Sent from a fat crate under my desk. Formatting is fine.
> --

Ok. Agree, 1024 is too small. Nice to know that:)

Merci.

-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¥