Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1264247 > unrolled thread
| Started by | Josh Boyer <jwboyer@fedoraproject.org> |
|---|---|
| First post | 2015-11-06 20:30 +0100 |
| Last post | 2015-11-09 11:20 +0100 |
| Articles | 4 — 3 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH 2/6] x86/microcode: Merge early loader Josh Boyer <jwboyer@fedoraproject.org> - 2015-11-06 20:30 +0100
Re: [PATCH 2/6] x86/microcode: Merge early loader Borislav Petkov <bp@alien8.de> - 2015-11-06 20:40 +0100
Re: [PATCH 2/6] x86/microcode: Merge early loader Harald Hoyer <harald@redhat.com> - 2015-11-09 10:50 +0100
Re: [PATCH 2/6] x86/microcode: Merge early loader Borislav Petkov <bp@alien8.de> - 2015-11-09 11:20 +0100
| From | Josh Boyer <jwboyer@fedoraproject.org> |
|---|---|
| Date | 2015-11-06 20:30 +0100 |
| Subject | Re: [PATCH 2/6] x86/microcode: Merge early loader |
| Message-ID | <qrURY-d0-11@gated-at.bofh.it> |
On Tue, Oct 20, 2015 at 5:54 AM, Borislav Petkov <bp@alien8.de> wrote: > From: Borislav Petkov <bp@suse.de> > > Merge the early loader functionality into the driver proper. The diff > is huge but logically, it is simply moving code from the _early.c files > into the main driver. > > Signed-off-by: Borislav Petkov <bp@suse.de> > --- > arch/x86/Kconfig | 19 +- > arch/x86/include/asm/microcode.h | 19 +- > arch/x86/include/asm/microcode_amd.h | 2 +- > arch/x86/include/asm/microcode_intel.h | 10 +- > arch/x86/kernel/cpu/microcode/Makefile | 3 - > arch/x86/kernel/cpu/microcode/amd.c | 446 ++++++++++++++- > arch/x86/kernel/cpu/microcode/amd_early.c | 444 --------------- > arch/x86/kernel/cpu/microcode/core.c | 160 +++++- > arch/x86/kernel/cpu/microcode/core_early.c | 170 ------ > arch/x86/kernel/cpu/microcode/intel.c | 788 ++++++++++++++++++++++++++- > arch/x86/kernel/cpu/microcode/intel_early.c | 808 ---------------------------- > arch/x86/kernel/head_32.S | 5 +- > arch/x86/mm/init.c | 2 - > 13 files changed, 1399 insertions(+), 1477 deletions(-) > delete mode 100644 arch/x86/kernel/cpu/microcode/amd_early.c > delete mode 100644 arch/x86/kernel/cpu/microcode/core_early.c > delete mode 100644 arch/x86/kernel/cpu/microcode/intel_early.c > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index fdf1f0cdf6b6..255ea22ccbec 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -1126,6 +1126,7 @@ config MICROCODE > bool "CPU microcode loading support" > default y > depends on CPU_SUP_AMD || CPU_SUP_INTEL > + depends on BLK_DEV_INITRD > select FW_LOADER > ---help--- > > @@ -1167,24 +1168,6 @@ config MICROCODE_OLD_INTERFACE > def_bool y > depends on MICROCODE > > -config MICROCODE_INTEL_EARLY > - bool > - > -config MICROCODE_AMD_EARLY > - bool > - > -config MICROCODE_EARLY > - bool "Early load microcode" > - depends on MICROCODE && BLK_DEV_INITRD > - select MICROCODE_INTEL_EARLY if MICROCODE_INTEL > - select MICROCODE_AMD_EARLY if MICROCODE_AMD > - default y > - help > - This option provides functionality to read additional microcode data > - at the beginning of initrd image. The data tells kernel to load > - microcode to CPU's as early as possible. No functional change if no > - microcode data is glued to the initrd, therefore it's safe to say Y. > - So this broke dracut. Dracut will look at the config file for the INTEL or AMD early config options being set. If it does not find them, it disables the creation of the early microcode part of the initramfs. Now that the options don't even exist, it fails. Do we have suggestions on how to work this out going forward? I suppose we could assume the check should only be done on 4.3 or older kernels, but I'm not sure making assumptions about newer kernels is a great idea either. josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [next] | [standalone]
| From | Borislav Petkov <bp@alien8.de> |
|---|---|
| Date | 2015-11-06 20:40 +0100 |
| Message-ID | <qrV1F-gl-37@gated-at.bofh.it> |
| In reply to | #1264247 |
On Fri, Nov 06, 2015 at 02:22:42PM -0500, Josh Boyer wrote:
> So this broke dracut. Dracut will look at the config file for the
> INTEL or AMD early config options being set.
Nothing outside the kernel should depend on Kconfig symbols.
> Do we have suggestions on how to work this out going forward? I
> suppose we could assume the check should only be done on 4.3 or older
> kernels, but I'm not sure making assumptions about newer kernels is a
> great idea either.
How about always adding AMD and Intel microcode always? Maybe with a
switch to disable adding any microcode for testing purposes only...
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Harald Hoyer <harald@redhat.com> |
|---|---|
| Date | 2015-11-09 10:50 +0100 |
| Message-ID | <qsRfk-4E2-17@gated-at.bofh.it> |
| In reply to | #1264293 |
Am 06.11.2015 um 20:31 schrieb Borislav Petkov: > On Fri, Nov 06, 2015 at 02:22:42PM -0500, Josh Boyer wrote: >> So this broke dracut. Dracut will look at the config file for the >> INTEL or AMD early config options being set. > > Nothing outside the kernel should depend on Kconfig symbols. > >> Do we have suggestions on how to work this out going forward? I >> suppose we could assume the check should only be done on 4.3 or older >> kernels, but I'm not sure making assumptions about newer kernels is a >> great idea either. > > How about always adding AMD and Intel microcode always? Maybe with a > switch to disable adding any microcode for testing purposes only... > Will this work with kernels not supporting the microcode loading? Theoretically the old kernels would just unpack all cpios one after the other, right? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Borislav Petkov <bp@alien8.de> |
|---|---|
| Date | 2015-11-09 11:20 +0100 |
| Message-ID | <qsRIo-55g-57@gated-at.bofh.it> |
| In reply to | #1265493 |
On Mon, Nov 09, 2015 at 10:42:13AM +0100, Harald Hoyer wrote:
> Will this work with kernels not supporting the microcode loading?
> Theoretically the old kernels would just unpack all cpios one after
> the other, right?
Well, what we should be doing is adding two paths to the initrd:
for AMD: kernel/x86/microcode/AuthenticAMD.bin
for Intel: kernel/x86/microcode/GenuineIntel.bin
I.e., the microcode blobs become part of the initrd, see
Documentation/x86/early-microcode.txt. The loader goes and opens the one
it needs at boot time.
You could also add a switch for convenience, something like
--no-microcode or so, so that dracut doesn't add it but if one wants to
not add microcode, one could also move it away from, say, /lib/firmware/
so that dracut simply doesn't find it. The --no-microcode might be more
convenient though.
Kernels which don't support microcode loading would simply not look for
that path.
Let me know if this doesn't make sense and if I need to test/look at
patches.
Thanks.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web