Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Linux: Kernel

[PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode

 

 

Linux kernel RSS feed   Index | Next | Previous | View Threaded


fenghua.yu at intel

Aug 18, 2012, 1:15 AM

Post #1 of 17 (150 views)
Permalink
[PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode

From: Fenghua Yu <fenghua.yu [at] intel>

Define interfaces load_ucode_bsp() and load_ucode_ap() to load ucode on BSP and
AP in early boot time. These are generic interfaces. Internally they call
vendor specific implementations.

Signed-off-by: Fenghua Yu <fenghua.yu [at] intel>
---
arch/x86/include/asm/microcode.h | 23 ++++++++++
arch/x86/kernel/microcode_core_early.c | 74 ++++++++++++++++++++++++++++++++
2 files changed, 97 insertions(+), 0 deletions(-)
create mode 100644 arch/x86/kernel/microcode_core_early.c

diff --git a/arch/x86/include/asm/microcode.h b/arch/x86/include/asm/microcode.h
index 4ebe157..080ea77 100644
--- a/arch/x86/include/asm/microcode.h
+++ b/arch/x86/include/asm/microcode.h
@@ -63,4 +63,27 @@ static inline struct microcode_ops * __init init_amd_microcode(void)
static inline void __exit exit_amd_microcode(void) {}
#endif

+struct mc_saved_data {
+ unsigned int mc_saved_count;
+ struct microcode_intel **mc_saved;
+ struct ucode_cpu_info *ucode_cpu_info;
+};
+#ifdef CONFIG_MICROCODE_EARLY
+#define MAX_UCODE_COUNT 128
+extern struct ucode_cpu_info ucode_cpu_info_early[NR_CPUS];
+extern struct microcode_intel __initdata *mc_saved_in_initrd[MAX_UCODE_COUNT];
+extern struct mc_saved_data mc_saved_data;
+extern void __init load_ucode_bsp(char *real_mode_data);
+extern __init void load_ucode_ap(void);
+extern void __init
+save_microcode_in_initrd(struct mc_saved_data *mc_saved_data,
+ struct microcode_intel **mc_saved_in_initrd);
+#else
+static inline void __init load_ucode_bsp(char *real_mode_data) {}
+static inline __init void load_ucode_ap(void) {}
+static inline void __init
+save_microcode_in_initrd(struct mc_saved_data *mc_saved_data,
+ struct microcode_intel **mc_saved_in_initrd) {}
+#endif
+
#endif /* _ASM_X86_MICROCODE_H */
diff --git a/arch/x86/kernel/microcode_core_early.c b/arch/x86/kernel/microcode_core_early.c
new file mode 100644
index 0000000..5bcc6f8
--- /dev/null
+++ b/arch/x86/kernel/microcode_core_early.c
@@ -0,0 +1,74 @@
+/*
+ * X86 CPU microcode early update for Linux
+ *
+ * Copyright (C) 2012 Fenghua Yu <fenghua.yu [at] intel>
+ * H Peter Anvin" <hpa [at] zytor>
+ *
+ * This driver allows to early upgrade microcode on Intel processors
+ * belonging to IA-32 family - PentiumPro, Pentium II,
+ * Pentium III, Xeon, Pentium 4, etc.
+ *
+ * Reference: Section 9.11 of Volume 3, IA-32 Intel Architecture
+ * Software Developer's Manual.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+#include <linux/module.h>
+#include <linux/mm.h>
+#include <asm/microcode_intel.h>
+#include <asm/processor.h>
+#include <asm/cpio.h>
+
+struct ucode_cpu_info ucode_cpu_info_early[NR_CPUS];
+EXPORT_SYMBOL_GPL(ucode_cpu_info_early);
+
+static __init enum ucode_state
+find_ucode_intel(unsigned long start, unsigned long end)
+{
+ unsigned int size = end - start + 1;
+ struct cpio_data cd = { 0, 0 };
+ char ucode_name[] = "kernel/x86/microcode/GenuineIntel/microcode.hex";
+
+ cd = find_cpio_data(ucode_name, (void *)start, size);
+ if (cd.data)
+ return UCODE_OK;
+
+ return UCODE_ERROR;
+}
+
+void __init load_ucode_bsp(char *real_mode_data)
+{
+ u64 ramdisk_image, ramdisk_size, ramdisk_end;
+ unsigned long initrd_start, initrd_end;
+ struct boot_params *boot_params;
+
+ boot_params = (struct boot_params *)real_mode_data;
+ ramdisk_image = boot_params->hdr.ramdisk_image;
+ ramdisk_size = boot_params->hdr.ramdisk_size;
+
+#ifdef CONFIG_X86_64
+ ramdisk_end = PAGE_ALIGN(ramdisk_image + ramdisk_size);
+ initrd_start = ramdisk_image + PAGE_OFFSET;
+#else
+ ramdisk_end = ramdisk_image + ramdisk_size;
+ initrd_start = ramdisk_image;
+#endif
+ initrd_end = initrd_start + ramdisk_size;
+
+ /*
+ * It's early to get CPU vendor info at this point.
+ * By searching initrd to find right name for vendor's microcode,
+ * it's relative easier to get CPU vendor info.
+ */
+ if (find_ucode_intel(initrd_start, initrd_end) == UCODE_OK)
+ load_ucode_intel_bsp(real_mode_data);
+}
+
+void __cpuinit load_ucode_ap(void)
+{
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL)
+ load_ucode_intel_ap();
+}
--
1.7.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


hmh at hmh

Aug 18, 2012, 3:44 PM

Post #2 of 17 (139 views)
Permalink
Re: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode [In reply to]

On Sat, 18 Aug 2012, Fenghua Yu wrote:
> + char ucode_name[] = "kernel/x86/microcode/GenuineIntel/microcode.hex";

Why name it ".hex" when you're loading binary data? I suggest ".bin". It
is confusing to have .hex there, since you're not dealing with the Intel HEX
format, nor anything text-like.

> +void __init load_ucode_bsp(char *real_mode_data)
> +{
> + u64 ramdisk_image, ramdisk_size, ramdisk_end;
> + unsigned long initrd_start, initrd_end;
> + struct boot_params *boot_params;
> +
> + boot_params = (struct boot_params *)real_mode_data;
> + ramdisk_image = boot_params->hdr.ramdisk_image;
> + ramdisk_size = boot_params->hdr.ramdisk_size;
> +
> +#ifdef CONFIG_X86_64
> + ramdisk_end = PAGE_ALIGN(ramdisk_image + ramdisk_size);
> + initrd_start = ramdisk_image + PAGE_OFFSET;
> +#else
> + ramdisk_end = ramdisk_image + ramdisk_size;
> + initrd_start = ramdisk_image;
> +#endif
> + initrd_end = initrd_start + ramdisk_size;
> +
> + /*
> + * It's early to get CPU vendor info at this point.
> + * By searching initrd to find right name for vendor's microcode,
> + * it's relative easier to get CPU vendor info.
> + */
> + if (find_ucode_intel(initrd_start, initrd_end) == UCODE_OK)
> + load_ucode_intel_bsp(real_mode_data);
> +}

I'd say something down the load_ucode_intel_bsp() chain better check the CPU
vendor to make sure the Intel driver won't attempt to load microcode on some
other vendor's processor.

Or are cpu signatures a global namespace and x86 cpu vendors make sure
(past, present and future) to never use the same cpu signature as someone
else is going to use? Anyway, it would still might be a good thing to do
the vendor check somewhere to avoid wasting time going over every microcode
of the wrong vendor on generic boot images that have both AMD and Intel
microcode.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


fenghua.yu at intel

Aug 18, 2012, 7:38 PM

Post #3 of 17 (139 views)
Permalink
RE: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode [In reply to]

> -----Original Message-----
> From: Henrique de Moraes Holschuh [mailto:hmh [at] hmh]
> Sent: Saturday, August 18, 2012 3:45 PM
> 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 04/11] x86/microcode_core_early.c: Define
> interfaces for early load ucode
>
> On Sat, 18 Aug 2012, Fenghua Yu wrote:
> > + char ucode_name[] =
> "kernel/x86/microcode/GenuineIntel/microcode.hex";
>
> Why name it ".hex" when you're loading binary data? I suggest ".bin".
> It
> is confusing to have .hex there, since you're not dealing with the
> Intel HEX
> format, nor anything text-like.
>
> > +void __init load_ucode_bsp(char *real_mode_data)
> > +{
> > + u64 ramdisk_image, ramdisk_size, ramdisk_end;
> > + unsigned long initrd_start, initrd_end;
> > + struct boot_params *boot_params;
> > +
> > + boot_params = (struct boot_params *)real_mode_data;
> > + ramdisk_image = boot_params->hdr.ramdisk_image;
> > + ramdisk_size = boot_params->hdr.ramdisk_size;
> > +
> > +#ifdef CONFIG_X86_64
> > + ramdisk_end = PAGE_ALIGN(ramdisk_image + ramdisk_size);
> > + initrd_start = ramdisk_image + PAGE_OFFSET;
> > +#else
> > + ramdisk_end = ramdisk_image + ramdisk_size;
> > + initrd_start = ramdisk_image;
> > +#endif
> > + initrd_end = initrd_start + ramdisk_size;
> > +
> > + /*
> > + * It's early to get CPU vendor info at this point.
> > + * By searching initrd to find right name for vendor's microcode,
> > + * it's relative easier to get CPU vendor info.
> > + */
> > + if (find_ucode_intel(initrd_start, initrd_end) == UCODE_OK)
> > + load_ucode_intel_bsp(real_mode_data);
> > +}
>
> I'd say something down the load_ucode_intel_bsp() chain better check
> the CPU
> vendor to make sure the Intel driver won't attempt to load microcode on
> some
> other vendor's processor.
>
> Or are cpu signatures a global namespace and x86 cpu vendors make sure
> (past, present and future) to never use the same cpu signature as
> someone
> else is going to use? Anyway, it would still might be a good thing to
> do
> the vendor check somewhere to avoid wasting time going over every
> microcode
> of the wrong vendor on generic boot images that have both AMD and Intel
> microcode.
>

In this early phase, detecting vendor in initrd is much simpler code. Otherwise, detecting vendor by cpuid (and without cpuid) needs similar but different code as existing functions and coding would be awkward.

I fully thought and agreed the usage complexity you describe here. It might be good thing to do a bit ugly but more practical coding here.

Thanks.

-Fenghua
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


hmh at hmh

Aug 18, 2012, 9:43 PM

Post #4 of 17 (139 views)
Permalink
Re: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode [In reply to]

On Sun, 19 Aug 2012, Yu, Fenghua wrote:
> > From: Henrique de Moraes Holschuh [mailto:hmh [at] hmh]
> > On Sat, 18 Aug 2012, Fenghua Yu wrote:
> > > + char ucode_name[] =
> > "kernel/x86/microcode/GenuineIntel/microcode.hex";
> >
> > Why name it ".hex" when you're loading binary data? I suggest ".bin".
> > It
> > is confusing to have .hex there, since you're not dealing with the
> > Intel HEX
> > format, nor anything text-like.
> >
> > > +void __init load_ucode_bsp(char *real_mode_data)
> > > +{
> > > + u64 ramdisk_image, ramdisk_size, ramdisk_end;
> > > + unsigned long initrd_start, initrd_end;
> > > + struct boot_params *boot_params;
> > > +
> > > + boot_params = (struct boot_params *)real_mode_data;
> > > + ramdisk_image = boot_params->hdr.ramdisk_image;
> > > + ramdisk_size = boot_params->hdr.ramdisk_size;
> > > +
> > > +#ifdef CONFIG_X86_64
> > > + ramdisk_end = PAGE_ALIGN(ramdisk_image + ramdisk_size);
> > > + initrd_start = ramdisk_image + PAGE_OFFSET;
> > > +#else
> > > + ramdisk_end = ramdisk_image + ramdisk_size;
> > > + initrd_start = ramdisk_image;
> > > +#endif
> > > + initrd_end = initrd_start + ramdisk_size;
> > > +
> > > + /*
> > > + * It's early to get CPU vendor info at this point.
> > > + * By searching initrd to find right name for vendor's microcode,
> > > + * it's relative easier to get CPU vendor info.
> > > + */
> > > + if (find_ucode_intel(initrd_start, initrd_end) == UCODE_OK)
> > > + load_ucode_intel_bsp(real_mode_data);
> > > +}
> >
> > I'd say something down the load_ucode_intel_bsp() chain better check
> > the CPU
> > vendor to make sure the Intel driver won't attempt to load microcode on
> > some
> > other vendor's processor.
> >
> > Or are cpu signatures a global namespace and x86 cpu vendors make sure
> > (past, present and future) to never use the same cpu signature as
> > someone
> > else is going to use? Anyway, it would still might be a good thing to
> > do
> > the vendor check somewhere to avoid wasting time going over every
> > microcode
> > of the wrong vendor on generic boot images that have both AMD and Intel
> > microcode.
> >
>
> In this early phase, detecting vendor in initrd is much simpler code. Otherwise, detecting vendor by cpuid (and without cpuid) needs similar but different code as existing functions and coding would be awkward.
>
> I fully thought and agreed the usage complexity you describe here. It might be good thing to do a bit ugly but more practical coding here.

Sure, there is no harm in defering the implementation of this check to later
versions of the patch set. As long as the final patch set doesn't risk
loading microcode on the wrong vendor or waste a lot of milliseconds trying
to match intel microcode to a non-intel cpu, I have no objections :-)

But what about the ".hex" naming for the microcode bundle (container) name?
I find it confusing, since the file contains binary data, not structured
text representing binary data using base 16... this is also something that
is of minor importance, but at least it is a very easy thing to change at
this point.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


hpa at zytor

Aug 18, 2012, 10:24 PM

Post #5 of 17 (139 views)
Permalink
Re: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode [In reply to]

On 08/18/2012 07:38 PM, Yu, Fenghua wrote:
>
> In this early phase, detecting vendor in initrd is much simpler code.
> Otherwise, detecting vendor by cpuid (and without cpuid) needs
> similar but different code as existing functions and coding would be
> awkward.
>

I'm confused by this statement. Getting the vendor from CPUID is a few
lines of code, and non-CPUID processors don't support microcode loading.

> Why name it ".hex" when you're loading binary data? I suggest ".bin". It
> is confusing to have .hex there, since you're not dealing with the Intel HEX
> format, nor anything text-like.

Actually I think we can also skip one level of indirection here... no
need to mention "microcode" twice.

kernel/x86/microcode/GenuineIntel or GenuineIntel.bin seems good
enough... the idea here of course is that the string can come from CPUID.

-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


fenghua.yu at intel

Aug 19, 2012, 9:39 AM

Post #6 of 17 (139 views)
Permalink
RE: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode [In reply to]

> -----Original Message-----
> From: H. Peter Anvin [mailto:hpa [at] zytor]
> Sent: Saturday, August 18, 2012 10:25 PM
> To: Yu, Fenghua
> Cc: Henrique de Moraes Holschuh; Ingo Molnar; Thomas Gleixner; Mallick,
> Asit K; Tigran Aivazian; Andreas Herrmann; Borislav Petkov; linux-
> kernel; x86
> Subject: Re: [PATCH 04/11] x86/microcode_core_early.c: Define
> interfaces for early load ucode
>
> On 08/18/2012 07:38 PM, Yu, Fenghua wrote:
> >
> > In this early phase, detecting vendor in initrd is much simpler code.
> > Otherwise, detecting vendor by cpuid (and without cpuid) needs
> > similar but different code as existing functions and coding would be
> > awkward.
> >
>
> I'm confused by this statement. Getting the vendor from CPUID is a few
> lines of code, and non-CPUID processors don't support microcode loading.
>
Will checking vendor info from CPUID in next version.

> > Why name it ".hex" when you're loading binary data? I suggest ".bin".
> It
> > is confusing to have .hex there, since you're not dealing with the
> Intel HEX
> > format, nor anything text-like.
>
> Actually I think we can also skip one level of indirection here... no
> need to mention "microcode" twice.
>
> kernel/x86/microcode/GenuineIntel or GenuineIntel.bin seems good
> enough... the idea here of course is that the string can come from
> CPUID.
That's right. Will do this.

Thanks.

-Fenghua
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


bp at amd64

Aug 20, 2012, 7:04 AM

Post #7 of 17 (133 views)
Permalink
Re: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode [In reply to]

On Sat, Aug 18, 2012 at 01:15:22AM -0700, Fenghua Yu wrote:
> From: Fenghua Yu <fenghua.yu [at] intel>
>
> Define interfaces load_ucode_bsp() and load_ucode_ap() to load ucode on BSP and
> AP in early boot time. These are generic interfaces. Internally they call
> vendor specific implementations.
>
> Signed-off-by: Fenghua Yu <fenghua.yu [at] intel>
> ---
> arch/x86/include/asm/microcode.h | 23 ++++++++++
> arch/x86/kernel/microcode_core_early.c | 74 ++++++++++++++++++++++++++++++++
> 2 files changed, 97 insertions(+), 0 deletions(-)

Still the same build error:

ERROR: "get_matching_microcode" [arch/x86/kernel/microcode.ko] undefined!
ERROR: "microcode_sanity_check" [arch/x86/kernel/microcode.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
make: *** Waiting for unfinished jobs....


> create mode 100644 arch/x86/kernel/microcode_core_early.c
>
> diff --git a/arch/x86/include/asm/microcode.h b/arch/x86/include/asm/microcode.h
> index 4ebe157..080ea77 100644
> --- a/arch/x86/include/asm/microcode.h
> +++ b/arch/x86/include/asm/microcode.h
> @@ -63,4 +63,27 @@ static inline struct microcode_ops * __init init_amd_microcode(void)
> static inline void __exit exit_amd_microcode(void) {}
> #endif
>
> +struct mc_saved_data {
> + unsigned int mc_saved_count;
> + struct microcode_intel **mc_saved;
> + struct ucode_cpu_info *ucode_cpu_info;
> +};
> +#ifdef CONFIG_MICROCODE_EARLY
> +#define MAX_UCODE_COUNT 128
> +extern struct ucode_cpu_info ucode_cpu_info_early[NR_CPUS];
> +extern struct microcode_intel __initdata *mc_saved_in_initrd[MAX_UCODE_COUNT];
> +extern struct mc_saved_data mc_saved_data;
> +extern void __init load_ucode_bsp(char *real_mode_data);
> +extern __init void load_ucode_ap(void);
> +extern void __init
> +save_microcode_in_initrd(struct mc_saved_data *mc_saved_data,
> + struct microcode_intel **mc_saved_in_initrd);
> +#else
> +static inline void __init load_ucode_bsp(char *real_mode_data) {}
> +static inline __init void load_ucode_ap(void) {}
> +static inline void __init
> +save_microcode_in_initrd(struct mc_saved_data *mc_saved_data,
> + struct microcode_intel **mc_saved_in_initrd) {}
> +#endif
> +
> #endif /* _ASM_X86_MICROCODE_H */
> diff --git a/arch/x86/kernel/microcode_core_early.c b/arch/x86/kernel/microcode_core_early.c
> new file mode 100644
> index 0000000..5bcc6f8
> --- /dev/null
> +++ b/arch/x86/kernel/microcode_core_early.c
> @@ -0,0 +1,74 @@
> +/*
> + * X86 CPU microcode early update for Linux
> + *
> + * Copyright (C) 2012 Fenghua Yu <fenghua.yu [at] intel>
> + * H Peter Anvin" <hpa [at] zytor>
> + *
> + * This driver allows to early upgrade microcode on Intel processors
> + * belonging to IA-32 family - PentiumPro, Pentium II,
> + * Pentium III, Xeon, Pentium 4, etc.

Can we drop the vendor-specific text from generic x86 code pls? This
belongs into microcode_intel_* AFAICT.

> + *
> + * Reference: Section 9.11 of Volume 3, IA-32 Intel Architecture
> + * Software Developer's Manual.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + */
> +#include <linux/module.h>
> +#include <linux/mm.h>
> +#include <asm/microcode_intel.h>
> +#include <asm/processor.h>
> +#include <asm/cpio.h>
> +
> +struct ucode_cpu_info ucode_cpu_info_early[NR_CPUS];
> +EXPORT_SYMBOL_GPL(ucode_cpu_info_early);
> +
> +static __init enum ucode_state
> +find_ucode_intel(unsigned long start, unsigned long end)
> +{
> + unsigned int size = end - start + 1;
> + struct cpio_data cd = { 0, 0 };
> + char ucode_name[] = "kernel/x86/microcode/GenuineIntel/microcode.hex";
> +
> + cd = find_cpio_data(ucode_name, (void *)start, size);
> + if (cd.data)
> + return UCODE_OK;
> +
> + return UCODE_ERROR;
> +}

This function can be made generic by giving the ucode_name down as an
arg, for example, so that other vendors can use it too.

> +
> +void __init load_ucode_bsp(char *real_mode_data)
> +{
> + u64 ramdisk_image, ramdisk_size, ramdisk_end;
> + unsigned long initrd_start, initrd_end;
> + struct boot_params *boot_params;
> +
> + boot_params = (struct boot_params *)real_mode_data;
> + ramdisk_image = boot_params->hdr.ramdisk_image;
> + ramdisk_size = boot_params->hdr.ramdisk_size;
> +
> +#ifdef CONFIG_X86_64
> + ramdisk_end = PAGE_ALIGN(ramdisk_image + ramdisk_size);
> + initrd_start = ramdisk_image + PAGE_OFFSET;
> +#else
> + ramdisk_end = ramdisk_image + ramdisk_size;
> + initrd_start = ramdisk_image;
> +#endif
> + initrd_end = initrd_start + ramdisk_size;
> +
> + /*
> + * It's early to get CPU vendor info at this point.
> + * By searching initrd to find right name for vendor's microcode,
> + * it's relative easier to get CPU vendor info.
> + */
> + if (find_ucode_intel(initrd_start, initrd_end) == UCODE_OK)
> + load_ucode_intel_bsp(real_mode_data);
> +}
> +
> +void __cpuinit load_ucode_ap(void)
> +{
> + if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL)
> + load_ucode_intel_ap();
> +}
> --
> 1.7.2
>
>

--
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


bp at amd64

Aug 20, 2012, 7:06 AM

Post #8 of 17 (133 views)
Permalink
Re: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode [In reply to]

On Sun, Aug 19, 2012 at 04:39:42PM +0000, Yu, Fenghua wrote:
> > Actually I think we can also skip one level of indirection here... no
> > need to mention "microcode" twice.
> >
> > kernel/x86/microcode/GenuineIntel or GenuineIntel.bin seems good
> > enough... the idea here of course is that the string can come from
> > CPUID.
> That's right. Will do this.

Or,

in case we want to supply more vendor-specific stuff early at boot, we
could do:

kernel/x86/<vendor>/microcode...
|-> bios_overrides
|-> ...

and have this layout extensible from the beginning...

--
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


hpa at zytor

Aug 20, 2012, 1:08 PM

Post #9 of 17 (133 views)
Permalink
Re: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode [In reply to]

On 08/20/2012 07:06 AM, Borislav Petkov wrote:
>
> Or,
>
> in case we want to supply more vendor-specific stuff early at boot, we
> could do:
>
> kernel/x86/<vendor>/microcode...
> |-> bios_overrides
> |-> ...
>
> and have this layout extensible from the beginning...
>

Does that make sense, though? I'm a bit concerned about having multiple
files named microcode.bin by default; the pathname isn't as sticky as
the filename when people move things around...

-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


bp at amd64

Aug 20, 2012, 1:19 PM

Post #10 of 17 (133 views)
Permalink
Re: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode [In reply to]

On Mon, Aug 20, 2012 at 01:08:49PM -0700, H. Peter Anvin wrote:
> On 08/20/2012 07:06 AM, Borislav Petkov wrote:
> >
> > Or,
> >
> > in case we want to supply more vendor-specific stuff early at boot, we
> > could do:
> >
> > kernel/x86/<vendor>/microcode...
> > |-> bios_overrides
> > |-> ...
> >
> > and have this layout extensible from the beginning...
> >
> Does that make sense, though?

Only time will tell. I was simply saying that we should leave ourselves
the door opened, should we need functionality like that in the future.

> I'm a bit concerned about having multiple files named microcode.bin by
> default; the pathname isn't as sticky as the filename when people move
> things around...

Ok, I see.

How about the following scheme then:

kernel/x86/<vendor>-microcode.bin
kernel/x86/<vendor>-bios-overrides.blob
...

?

All I'm saying is maybe we should impose some sanity rules now before
people go crazy with this and things get out of hands...

--
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


fenghua.yu at intel

Aug 21, 2012, 1:05 PM

Post #11 of 17 (132 views)
Permalink
RE: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode [In reply to]

> -----Original Message-----
> From: Borislav Petkov [mailto:bp [at] amd64]
> Sent: Monday, August 20, 2012 1:20 PM
> To: H. Peter Anvin
> Cc: Yu, Fenghua; Henrique de Moraes Holschuh; Ingo Molnar; Thomas
> Gleixner; Mallick, Asit K; Tigran Aivazian; Andreas Herrmann; Borislav
> Petkov; linux-kernel; x86
> Subject: Re: [PATCH 04/11] x86/microcode_core_early.c: Define
> interfaces for early load ucode
>
> On Mon, Aug 20, 2012 at 01:08:49PM -0700, H. Peter Anvin wrote:
> > On 08/20/2012 07:06 AM, Borislav Petkov wrote:
> > >
> > > Or,
> > >
> > > in case we want to supply more vendor-specific stuff early at boot,
> we
> > > could do:
> > >
> > > kernel/x86/<vendor>/microcode...
> > > |-> bios_overrides
> > > |-> ...
> > >
> > > and have this layout extensible from the beginning...
> > >
> > Does that make sense, though?
>
> Only time will tell. I was simply saying that we should leave ourselves
> the door opened, should we need functionality like that in the future.
>
> > I'm a bit concerned about having multiple files named microcode.bin
> by
> > default; the pathname isn't as sticky as the filename when people
> move
> > things around...
>
> Ok, I see.
>
> How about the following scheme then:
>
> kernel/x86/<vendor>-microcode.bin
> kernel/x86/<vendor>-bios-overrides.blob
> ...
>
> ?
>
> All I'm saying is maybe we should impose some sanity rules now before
> people go crazy with this and things get out of hands...

We might name the cpio directory as:

kernel/x86/microcode/GenuineIntel.bin
kernel/x86/microcode/AuthenticAMD.bin
kernel/x86/acpi/...
etc.

This is expendable for the future usage.

Plus I will add a doc on the cpio directory, supported directory names and how to add new stuffs in the directory.

Thanks.

-Fenghua


Thanks.

-Fenghua
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


hpa at zytor

Aug 21, 2012, 1:13 PM

Post #12 of 17 (132 views)
Permalink
Re: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode [In reply to]

On 08/21/2012 01:05 PM, Yu, Fenghua wrote:
>
> We might name the cpio directory as:
>
> kernel/x86/microcode/GenuineIntel.bin
> kernel/x86/microcode/AuthenticAMD.bin
> kernel/x86/acpi/...
> etc.
>
> This is expendable for the future usage.
>
> Plus I will add a doc on the cpio directory, supported directory names and how to add new stuffs in the directory.
>

I believe that was exactly my original proposal. I think it makes
sense... most things aren't going to be inherently CPU-specific in this way.

I don't know what Borislav was suggesting with "BIOS overrides", is that
another CPU-specific thing?

-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


bp at amd64

Aug 21, 2012, 1:48 PM

Post #13 of 17 (134 views)
Permalink
Re: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode [In reply to]

On Tue, Aug 21, 2012 at 01:13:26PM -0700, H. Peter Anvin wrote:
> I don't know what Borislav was suggesting with "BIOS overrides", is
> that another CPU-specific thing?

Not CPU- but rather platform-specific. It is Thomas Renninger's
mechanism to override BIOS tables.

--
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


hpa at zytor

Aug 21, 2012, 1:52 PM

Post #14 of 17 (132 views)
Permalink
Re: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode [In reply to]

On 08/21/2012 01:48 PM, Borislav Petkov wrote:
> On Tue, Aug 21, 2012 at 01:13:26PM -0700, H. Peter Anvin wrote:
>> I don't know what Borislav was suggesting with "BIOS overrides", is
>> that another CPU-specific thing?
>
> Not CPU- but rather platform-specific. It is Thomas Renninger's
> mechanism to override BIOS tables.
>

s/BIOS/ACPI/... Yes, so really it doesn't have any meaningful reason to
live under the CPU vendor.

-hpa


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


fenghua.yu at intel

Aug 21, 2012, 1:52 PM

Post #15 of 17 (132 views)
Permalink
RE: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode [In reply to]

> -----Original Message-----
> From: Borislav Petkov [mailto:bp [at] amd64]
> Sent: Tuesday, August 21, 2012 1:49 PM
> To: H. Peter Anvin
> Cc: Yu, Fenghua; Henrique de Moraes Holschuh; Ingo Molnar; Thomas
> Gleixner; Mallick, Asit K; Tigran Aivazian; Andreas Herrmann; Borislav
> Petkov; linux-kernel; x86
> Subject: Re: [PATCH 04/11] x86/microcode_core_early.c: Define
> interfaces for early load ucode
>
> On Tue, Aug 21, 2012 at 01:13:26PM -0700, H. Peter Anvin wrote:
> > I don't know what Borislav was suggesting with "BIOS overrides", is
> > that another CPU-specific thing?
>
> Not CPU- but rather platform-specific. It is Thomas Renninger's
> mechanism to override BIOS tables.

That's ACPI override. I think the ACPI tables could be put in kernel/x86/acpi/.

Thanks.

-Fenghua

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


hpa at zytor

Aug 21, 2012, 1:53 PM

Post #16 of 17 (132 views)
Permalink
Re: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode [In reply to]

On 08/21/2012 01:52 PM, Yu, Fenghua wrote:
>> -----Original Message-----
>> From: Borislav Petkov [mailto:bp [at] amd64]
>> Sent: Tuesday, August 21, 2012 1:49 PM
>> To: H. Peter Anvin
>> Cc: Yu, Fenghua; Henrique de Moraes Holschuh; Ingo Molnar; Thomas
>> Gleixner; Mallick, Asit K; Tigran Aivazian; Andreas Herrmann; Borislav
>> Petkov; linux-kernel; x86
>> Subject: Re: [PATCH 04/11] x86/microcode_core_early.c: Define
>> interfaces for early load ucode
>>
>> On Tue, Aug 21, 2012 at 01:13:26PM -0700, H. Peter Anvin wrote:
>>> I don't know what Borislav was suggesting with "BIOS overrides", is
>>> that another CPU-specific thing?
>>
>> Not CPU- but rather platform-specific. It is Thomas Renninger's
>> mechanism to override BIOS tables.
>
> That's ACPI override. I think the ACPI tables could be put in kernel/x86/acpi/.
>

kernel/acpi... ACPI is not x86-specific.

-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


fenghua.yu at intel

Aug 21, 2012, 1:58 PM

Post #17 of 17 (132 views)
Permalink
RE: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode [In reply to]

> -----Original Message-----
> From: H. Peter Anvin [mailto:hpa [at] zytor]
> Sent: Tuesday, August 21, 2012 1:54 PM
> To: Yu, Fenghua
> Cc: Borislav Petkov; Henrique de Moraes Holschuh; Ingo Molnar; Thomas
> Gleixner; Mallick, Asit K; Tigran Aivazian; Andreas Herrmann; Borislav
> Petkov; linux-kernel; x86
> Subject: Re: [PATCH 04/11] x86/microcode_core_early.c: Define
> interfaces for early load ucode
>
> On 08/21/2012 01:52 PM, Yu, Fenghua wrote:
> >> -----Original Message-----
> >> From: Borislav Petkov [mailto:bp [at] amd64]
> >> Sent: Tuesday, August 21, 2012 1:49 PM
> >> To: H. Peter Anvin
> >> Cc: Yu, Fenghua; Henrique de Moraes Holschuh; Ingo Molnar; Thomas
> >> Gleixner; Mallick, Asit K; Tigran Aivazian; Andreas Herrmann;
> Borislav
> >> Petkov; linux-kernel; x86
> >> Subject: Re: [PATCH 04/11] x86/microcode_core_early.c: Define
> >> interfaces for early load ucode
> >>
> >> On Tue, Aug 21, 2012 at 01:13:26PM -0700, H. Peter Anvin wrote:
> >>> I don't know what Borislav was suggesting with "BIOS overrides", is
> >>> that another CPU-specific thing?
> >>
> >> Not CPU- but rather platform-specific. It is Thomas Renninger's
> >> mechanism to override BIOS tables.
> >
> > That's ACPI override. I think the ACPI tables could be put in
> kernel/x86/acpi/.
> >
>
> kernel/acpi... ACPI is not x86-specific.

That's right.

Thanks.

-Fenghua
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Linux kernel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.