[PATCH 00/11] x86/microcode: Early load microcode

[PATCH 00/11] x86/microcode: Early load microcode

[Fenghua Yu]

From: Fenghua Yu <fenghua.yu@intel.com>

The problem in current microcode loading method is that we load a microcode way,
way too late; ideally we should load it before turning paging on.  This may only
be practical on 32 bits since we can't get to 64-bit mode without paging on,
but we should still do it as early as at all possible.

Similarly, we should load the microcode update as early as possible during AP
bringup and when processors are brought back online after hotplug or S3/S4.

In order to do that, the microcode patch needs to be permanently present in
kernel memory.  Each individual patch is fairly small, so that is OK, but the
entire blob with support for each CPU is too big. Since only CPU's with same
model can be in the same platform, we store microcode with the same model as
BSP. Later on AP's can upload microcode from the saved microcodep patches.

Note, however, that Linux users have gotten used to being able to install a
microcode patch in the field without having a reboot; we support that model too.

Fenghua Yu (11):
  Documentation/x86: Early load microcode
  x86/lib/cpio.c: Find cpio data by its file name
  x86/microcode_intel.h: Define functions and macros for early load
    ucode
  x86/microcode_core_early.c: Define interfaces for early load ucode
  x86/microcode_intel_lib.c: Early update ucode on Intel's CPU
  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/smpboot.c: Early update ucode on AP
  x86/mm/init.c: Copy ucode from initrd image to memory
  x86/Kconfig: Configurations to enable/disable the feature

 Documentation/x86/earlyucode.txt        |   43 +++
 arch/x86/Kconfig                        |   22 ++
 arch/x86/include/asm/cpio.h             |   10 +
 arch/x86/include/asm/microcode.h        |   23 ++
 arch/x86/include/asm/microcode_intel.h  |  103 +++++++
 arch/x86/kernel/Makefile                |    3 +
 arch/x86/kernel/head64.c                |    6 +
 arch/x86/kernel/head_32.S               |    6 +
 arch/x86/kernel/microcode_core.c        |    7 +-
 arch/x86/kernel/microcode_core_early.c  |   74 +++++
 arch/x86/kernel/microcode_intel.c       |  185 +------------
 arch/x86/kernel/microcode_intel_early.c |  482 +++++++++++++++++++++++++++++++
 arch/x86/kernel/microcode_intel_lib.c   |  163 +++++++++++
 arch/x86/kernel/smpboot.c               |    7 +
 arch/x86/lib/Makefile                   |    2 +
 arch/x86/lib/cpio.c                     |  179 ++++++++++++
 arch/x86/mm/init.c                      |   10 +
 17 files changed, 1144 insertions(+), 181 deletions(-)
 create mode 100644 Documentation/x86/earlyucode.txt
 create mode 100644 arch/x86/include/asm/cpio.h
 create mode 100644 arch/x86/include/asm/microcode_intel.h
 create mode 100644 arch/x86/kernel/microcode_core_early.c
 create mode 100644 arch/x86/kernel/microcode_intel_early.c
 create mode 100644 arch/x86/kernel/microcode_intel_lib.c
 create mode 100644 arch/x86/lib/cpio.c

-- 
1.7.2

Re: [PATCH 00/11] x86/microcode: Early load microcode

[Borislav Petkov]

On Sat, Aug 18, 2012 at 01:15:18AM -0700, Fenghua Yu wrote:
>  Documentation/x86/earlyucode.txt        |   43 +++
>  arch/x86/Kconfig                        |   22 ++
>  arch/x86/include/asm/cpio.h             |   10 +
>  arch/x86/include/asm/microcode.h        |   23 ++
>  arch/x86/include/asm/microcode_intel.h  |  103 +++++++
>  arch/x86/kernel/Makefile                |    3 +
>  arch/x86/kernel/head64.c                |    6 +
>  arch/x86/kernel/head_32.S               |    6 +
>  arch/x86/kernel/microcode_core.c        |    7 +-
>  arch/x86/kernel/microcode_core_early.c  |   74 +++++
>  arch/x86/kernel/microcode_intel.c       |  185 +------------
>  arch/x86/kernel/microcode_intel_early.c |  482 +++++++++++++++++++++++++++++++
>  arch/x86/kernel/microcode_intel_lib.c   |  163 +++++++++++

One more thing:

This screams for adding a directory called "microcode" in the kernel
sources and moving all the microcode-related files there. IOW:

arch/x86/kernel/cpu/microcode/core.c
arch/x86/kernel/cpu/microcode/core_early.c
arch/x86/kernel/cpu/microcode/intel.c
arch/x86/kernel/cpu/microcode/amd.c
...

And yes, they should be under "cpu" too.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

RE: [PATCH 00/11] x86/microcode: Early load microcode

[Yu, Fenghua]

> -----Original Message-----
> From: Borislav Petkov [mailto:bp@amd64.org]
> Sent: Monday, August 20, 2012 8:39 AM
> To: Yu, Fenghua
> Cc: H Peter Anvin; Ingo Molnar; Thomas Gleixner; Mallick, Asit K;
> Tigran Aivazian; Andreas Herrmann; Borislav Petkov; linux-kernel; x86
> Subject: Re: [PATCH 00/11] x86/microcode: Early load microcode
> 
> On Sat, Aug 18, 2012 at 01:15:18AM -0700, Fenghua Yu wrote:
> >  Documentation/x86/earlyucode.txt        |   43 +++
> >  arch/x86/Kconfig                        |   22 ++
> >  arch/x86/include/asm/cpio.h             |   10 +
> >  arch/x86/include/asm/microcode.h        |   23 ++
> >  arch/x86/include/asm/microcode_intel.h  |  103 +++++++
> >  arch/x86/kernel/Makefile                |    3 +
> >  arch/x86/kernel/head64.c                |    6 +
> >  arch/x86/kernel/head_32.S               |    6 +
> >  arch/x86/kernel/microcode_core.c        |    7 +-
> >  arch/x86/kernel/microcode_core_early.c  |   74 +++++
> >  arch/x86/kernel/microcode_intel.c       |  185 +------------
> >  arch/x86/kernel/microcode_intel_early.c |  482
> +++++++++++++++++++++++++++++++
> >  arch/x86/kernel/microcode_intel_lib.c   |  163 +++++++++++
> 
> One more thing:
> 
> This screams for adding a directory called "microcode" in the kernel
> sources and moving all the microcode-related files there. IOW:
> 
> arch/x86/kernel/cpu/microcode/core.c
> arch/x86/kernel/cpu/microcode/core_early.c
> arch/x86/kernel/cpu/microcode/intel.c
> arch/x86/kernel/cpu/microcode/amd.c
> ...
> 
> And yes, they should be under "cpu" too.

That's right.

Thanks.

-Fenghua

Re: [PATCH 00/11] x86/microcode: Early load microcode

[H. Peter Anvin]

On 08/20/2012 08:39 AM, Borislav Petkov wrote:
> On Sat, Aug 18, 2012 at 01:15:18AM -0700, Fenghua Yu wrote:
>>  Documentation/x86/earlyucode.txt        |   43 +++
>>  arch/x86/Kconfig                        |   22 ++
>>  arch/x86/include/asm/cpio.h             |   10 +
>>  arch/x86/include/asm/microcode.h        |   23 ++
>>  arch/x86/include/asm/microcode_intel.h  |  103 +++++++
>>  arch/x86/kernel/Makefile                |    3 +
>>  arch/x86/kernel/head64.c                |    6 +
>>  arch/x86/kernel/head_32.S               |    6 +
>>  arch/x86/kernel/microcode_core.c        |    7 +-
>>  arch/x86/kernel/microcode_core_early.c  |   74 +++++
>>  arch/x86/kernel/microcode_intel.c       |  185 +------------
>>  arch/x86/kernel/microcode_intel_early.c |  482 +++++++++++++++++++++++++++++++
>>  arch/x86/kernel/microcode_intel_lib.c   |  163 +++++++++++
> 
> One more thing:
> 
> This screams for adding a directory called "microcode" in the kernel
> sources and moving all the microcode-related files there. IOW:
> 
> arch/x86/kernel/cpu/microcode/core.c
> arch/x86/kernel/cpu/microcode/core_early.c
> arch/x86/kernel/cpu/microcode/intel.c
> arch/x86/kernel/cpu/microcode/amd.c
> ...
> 
> And yes, they should be under "cpu" too.
> 

Not really, but that isn't even Fenghua's fault.

The cpu directory was originally for cpu detection.  The whole kernel/
directory, of course, is a morass that might as well be called "misc".
Some things are legitimately there -- mainly the syscall table and
things that mirror the global kernel/ -- but a ton of stuff doesn't make
any sense there.

Reorganizing the kernel/ directory and promoting cpu up one level would
make that make more sense.  The pci and irq code are examples of things
that could use their own directories.

	-hpa

Re: [PATCH 00/11] x86/microcode: Early load microcode

[Borislav Petkov]

On Mon, Aug 20, 2012 at 11:51:14AM -0700, H. Peter Anvin wrote:
> Not really, but that isn't even Fenghua's fault.

Of course it isn't - I was simply pointing out that this is something
that should be fixed at some point in time, when someone needs a project
over an otherwise eventless weekend :-).

> The cpu directory was originally for cpu detection.  The whole kernel/
> directory, of course, is a morass that might as well be called "misc".
> Some things are legitimately there -- mainly the syscall table and
> things that mirror the global kernel/ -- but a ton of stuff doesn't make
> any sense there.
> 
> Reorganizing the kernel/ directory and promoting cpu up one level would

Yep, arch/x86/cpu, should contain all cpu-related stuff.

> make that make more sense.  The pci and irq code are examples of things
> that could use their own directories.

Yep.

Thanks.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

Re: [PATCH 00/11] x86/microcode: Early load microcode

[Jamie Gloudon]

Hey,

  Any chance of this getting merge for the 3.7 cycle? 

Regards,
Jamie Gloudon

Re: [PATCH 00/11] x86/microcode: Early load microcode

[Borislav Petkov]

On Mon, Oct 01, 2012 at 12:11:51PM -0400, Jamie Gloudon wrote:
> Hey,
> 
>   Any chance of this getting merge for the 3.7 cycle? 

It is not ready yet: http://marc.info/?l=linux-kernel&m=134910582107898

Out of curiosity: why do you nee it?

Thanks.

-- 
Regards/Gruss,
Boris.

Re: [PATCH 00/11] x86/microcode: Early load microcode

[Jamie Gloudon]

Seems like a better alternative to microcode_ctl which some distros don't
contain. 

Regards,
Jamie Gloudon

On Mon, Oct 01, 2012 at 06:27:45PM +0200, Borislav Petkov wrote:
> On Mon, Oct 01, 2012 at 12:11:51PM -0400, Jamie Gloudon wrote:
> > Hey,
> > 
> >   Any chance of this getting merge for the 3.7 cycle? 
> 
> It is not ready yet: http://marc.info/?l=linux-kernel&m=134910582107898
> 
> Out of curiosity: why do you nee it?
> 
> Thanks.
> 
> -- 
> Regards/Gruss,
> Boris.

Re: [PATCH 00/11] x86/microcode: Early load microcode

[Borislav Petkov]

On Mon, Oct 01, 2012 at 07:37:04PM -0400, Jamie Gloudon wrote:
> On Mon, Oct 01, 2012 at 06:27:45PM +0200, Borislav Petkov wrote:
> > On Mon, Oct 01, 2012 at 12:11:51PM -0400, Jamie Gloudon wrote:
> > > Hey,
> > > 
> > >   Any chance of this getting merge for the 3.7 cycle? 
> > 
> > It is not ready yet: http://marc.info/?l=linux-kernel&m=134910582107898
> > 
> > Out of curiosity: why do you nee it?
> > 
> Seems like a better alternative to microcode_ctl which some distros don't
> contain.

 [ Let me reorganize the mail chain as it should be,
   without top-posting. Please try not to top-post:
   http://curl.haxx.se/mail/etiquette.html#Do_Not_Top_Post ]


Well,

if you want to reload your microcode, you shouldn't be needing
microcode_ctl (I believe this should be the case too on Intel, from
staring at the code - on AMD it works).

Basically, you simply put the microcode binaries into
/lib/firmware/{amd,intel}-ucode/ and then do as root:

$ echo 1 > /sys/devices/system/cpu/microcode/reload

That's it, no need for special tools.

-- 
Regards/Gruss,
    Boris.

Re: [PATCH 00/11] x86/microcode: Early load microcode

[H. Peter Anvin]

On 10/01/2012 09:27 AM, Borislav Petkov wrote:
> On Mon, Oct 01, 2012 at 12:11:51PM -0400, Jamie Gloudon wrote:
>> Hey,
>>
>>    Any chance of this getting merge for the 3.7 cycle?
>
> It is not ready yet: http://marc.info/?l=linux-kernel&m=134910582107898
>

Yes, Fenghua who has been working on it unfortunately got preempted at 
an inopportune moment.  It will get fixed.

	-hpa


-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [PATCH 00/11] x86/microcode: Early load microcode

[Jamie Gloudon]

On Tue, Oct 02, 2012 at 06:39:54AM +0200, Borislav Petkov wrote:
> On Mon, Oct 01, 2012 at 07:37:04PM -0400, Jamie Gloudon wrote:
> > On Mon, Oct 01, 2012 at 06:27:45PM +0200, Borislav Petkov wrote:
> > > On Mon, Oct 01, 2012 at 12:11:51PM -0400, Jamie Gloudon wrote:
> > > > Hey,
> > > > 
> > > >   Any chance of this getting merge for the 3.7 cycle? 
> > > 
> > > It is not ready yet: http://marc.info/?l=linux-kernel&m=134910582107898
> > > 
> > > Out of curiosity: why do you nee it?
> > > 
> > Seems like a better alternative to microcode_ctl which some distros don't
> > contain.
> 
>  [ Let me reorganize the mail chain as it should be,
>    without top-posting. Please try not to top-post:
>    http://curl.haxx.se/mail/etiquette.html#Do_Not_Top_Post ]
> 
> 
> Well,
> 
> if you want to reload your microcode, you shouldn't be needing
> microcode_ctl (I believe this should be the case too on Intel, from
> staring at the code - on AMD it works).
> 
> Basically, you simply put the microcode binaries into
> /lib/firmware/{amd,intel}-ucode/ and then do as root:
> 
> $ echo 1 > /sys/devices/system/cpu/microcode/reload
> 
> That's it, no need for special tools.
> 
> -- 
> Regards/Gruss,
>     Boris.

My main interest was getting PEBS events support for perf on Intel SNB cpus. Loading the microcode at runtime was not going to work. 

However, thanks for pointing me in the right direction. I notice today this is not the case anymore from the thread below.

http://marc.info/?l=linux-kernel&m=133905353211963&w=2


Regards,
Jamie Gloudon

Re: [PATCH 00/11] x86/microcode: Early load microcode

[Borislav Petkov]

On Tue, Oct 02, 2012 at 09:11:38AM -0400, Jamie Gloudon wrote:
> My main interest was getting PEBS events support for perf on Intel SNB
> cpus. Loading the microcode at runtime was not going to work.
>
> However, thanks for pointing me in the right direction. I notice today
> this is not the case anymore from the thread below.
>
> http://marc.info/?l=linux-kernel&m=133905353211963&w=2

Yes, there's a perf callback from within the ucode driver to recheck
PEBS. This is in 3.6 so PEBS should work there with the required ucode
patch.

-- 
Regards/Gruss,
Boris.

Re: [PATCH 00/11] x86/microcode: Early load microcode

[Konrad Rzeszutek Wilk]

On Tue, Oct 2, 2012 at 2:06 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 10/01/2012 09:27 AM, Borislav Petkov wrote:
>>
>> On Mon, Oct 01, 2012 at 12:11:51PM -0400, Jamie Gloudon wrote:
>>>
>>> Hey,
>>>
>>>    Any chance of this getting merge for the 3.7 cycle?
>>
>>
>> It is not ready yet: http://marc.info/?l=linux-kernel&m=134910582107898
>>
>
> Yes, Fenghua who has been working on it unfortunately got preempted at an
> inopportune moment.  It will get fixed.


When he got interrupted did he have any beta patches to dracut that
could be posted?

Re: [PATCH 00/11] x86/microcode: Early load microcode

[H. Peter Anvin]

On 10/02/2012 12:00 PM, Konrad Rzeszutek Wilk wrote:
> 
> When he got interrupted did he have any beta patches to dracut that
> could be posted?
> 

To *dracut*?

	-hpa

RE: [PATCH 00/11] x86/microcode: Early load microcode

[Yu, Fenghua]

> On Tue, Oct 2, 2012 at 2:06 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> > On 10/01/2012 09:27 AM, Borislav Petkov wrote:
> >>
> >> On Mon, Oct 01, 2012 at 12:11:51PM -0400, Jamie Gloudon wrote:
> >>>
> >>> Hey,
> >>>
> >>>    Any chance of this getting merge for the 3.7 cycle?
> >>
> >>
> >> It is not ready yet: http://marc.info/?l=linux-
> kernel&m=134910582107898
> >>
> >
> > Yes, Fenghua who has been working on it unfortunately got preempted
> at an
> > inopportune moment.  It will get fixed.
> 
> 
> When he got interrupted did he have any beta patches to dracut that
> could be posted?

I'll post new patchset as soon as possible.

Thanks.

-Fenghua

Re: [PATCH 00/11] x86/microcode: Early load microcode

[Konrad Rzeszutek Wilk]

On Tue, Oct 2, 2012 at 3:04 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 10/02/2012 12:00 PM, Konrad Rzeszutek Wilk wrote:
>>
>> When he got interrupted did he have any beta patches to dracut that
>> could be posted?
>>
>
> To *dracut*?

The replacement for mkinitrd. You know the thing that creates your
initramfs.cpio.gz.

Re: [PATCH 00/11] x86/microcode: Early load microcode

[H. Peter Anvin]

On 10/03/2012 06:13 AM, Konrad Rzeszutek Wilk wrote:
> On Tue, Oct 2, 2012 at 3:04 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>> On 10/02/2012 12:00 PM, Konrad Rzeszutek Wilk wrote:
>>>
>>> When he got interrupted did he have any beta patches to dracut that
>>> could be posted?
>>>
>>
>> To *dracut*?
>
> The replacement for mkinitrd. You know the thing that creates your
> initramfs.cpio.gz.
>

Yes... it just seems that mucking with dracut is the last step in the 
chain.  If your boot loader doesn't support initramfs concatenation, (a) 
complain to your bootloader author, (b) you can just use "cat"...

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.