RE: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode
> -Original Message- > From: H. Peter Anvin [mailto:h...@zytor.com] > 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:b...@amd64.org] > >> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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:b...@amd64.org] >> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode
> -Original Message- > From: Borislav Petkov [mailto:b...@amd64.org] > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode
> -Original Message- > From: Borislav Petkov [mailto:b...@amd64.org] > 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//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/-microcode.bin > kernel/x86/-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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode
-Original Message- From: Borislav Petkov [mailto:b...@amd64.org] 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode
-Original Message- From: Borislav Petkov [mailto:b...@amd64.org] 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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:b...@amd64.org] 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode
-Original Message- From: H. Peter Anvin [mailto:h...@zytor.com] 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:b...@amd64.org] 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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//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/-microcode.bin kernel/x86/-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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode
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//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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode
On Sun, Aug 19, 2012 at 04:39:42PM +, 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//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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode
On Sat, Aug 18, 2012 at 01:15:22AM -0700, Fenghua Yu wrote:
> From: Fenghua Yu
>
> 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
> ---
> 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 000..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
> + * H Peter Anvin"
> + *
> + * 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
> +#include
> +#include
> +#include
> +#include
> +
> +struct ucode_cpu_infoucode_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)
Re: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode
On Sat, Aug 18, 2012 at 01:15:22AM -0700, Fenghua Yu wrote:
From: Fenghua Yu fenghua...@intel.com
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...@intel.com
---
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 000..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...@intel.com
+ * H Peter Anvin h...@zytor.com
+ *
+ * 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_infoucode_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,
Re: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode
On Sun, Aug 19, 2012 at 04:39:42PM +, 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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... -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode
> -Original Message- > From: H. Peter Anvin [mailto:h...@zytor.com] > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode
-Original Message- From: H. Peter Anvin [mailto:h...@zytor.com] 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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. > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode
On Sun, 19 Aug 2012, Yu, Fenghua wrote:
> > From: Henrique de Moraes Holschuh [mailto:h...@hmh.eng.br]
> > 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode
> -Original Message-
> From: Henrique de Moraes Holschuh [mailto:h...@hmh.eng.br]
> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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.
--
"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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode
From: Fenghua Yu
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
---
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 000..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
+ *H Peter Anvin"
+ *
+ * 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
+#include
+#include
+#include
+#include
+
+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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode
From: Fenghua Yu fenghua...@intel.com
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...@intel.com
---
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 000..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...@intel.com
+ *H Peter Anvin h...@zytor.com
+ *
+ * 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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.
--
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode
-Original Message-
From: Henrique de Moraes Holschuh [mailto:h...@hmh.eng.br]
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode
On Sun, 19 Aug 2012, Yu, Fenghua wrote:
From: Henrique de Moraes Holschuh [mailto:h...@hmh.eng.br]
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
