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

Mailing List Archive: Linux: Kernel

[PATCH 1/3] x86, ucode-amd: Load ucode-patches once and not separately fo each CPU

 

 

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


herrmann.der.user at googlemail

Nov 10, 2009, 3:07 AM

Post #1 of 5 (110 views)
Permalink
[PATCH 1/3] x86, ucode-amd: Load ucode-patches once and not separately fo each CPU

This also implies that corresponding log messages, e.g.

platform microcode: firmware: requesting amd-ucode/microcode_amd.bin

show up only once on module load and not when ucode is updated for
each CPU.

Signed-off-by: Andreas Herrmann <andreas.herrmann3 [at] amd>
---
arch/x86/include/asm/microcode.h | 2 ++
arch/x86/kernel/microcode_amd.c | 24 +++++++++++++++++-------
arch/x86/kernel/microcode_core.c | 6 ++++++
3 files changed, 25 insertions(+), 7 deletions(-)

diff --git a/arch/x86/include/asm/microcode.h b/arch/x86/include/asm/microcode.h
index ef51b50..c24ca9a 100644
--- a/arch/x86/include/asm/microcode.h
+++ b/arch/x86/include/asm/microcode.h
@@ -12,6 +12,8 @@ struct device;
enum ucode_state { UCODE_ERROR, UCODE_OK, UCODE_NFOUND };

struct microcode_ops {
+ void (*init)(struct device *device);
+ void (*fini)(void);
enum ucode_state (*request_microcode_user) (int cpu,
const void __user *buf, size_t size);

diff --git a/arch/x86/kernel/microcode_amd.c b/arch/x86/kernel/microcode_amd.c
index c043534..75538f6 100644
--- a/arch/x86/kernel/microcode_amd.c
+++ b/arch/x86/kernel/microcode_amd.c
@@ -33,6 +33,8 @@ MODULE_LICENSE("GPL v2");
#define UCODE_EQUIV_CPU_TABLE_TYPE 0x00000000
#define UCODE_UCODE_TYPE 0x00000001

+const struct firmware *firmware;
+
struct equiv_cpu_entry {
u32 installed_cpu;
u32 fixed_errata_mask;
@@ -301,14 +303,10 @@ generic_load_microcode(int cpu, const u8 *data, size_t size)

static enum ucode_state request_microcode_fw(int cpu, struct device *device)
{
- const char *fw_name = "amd-ucode/microcode_amd.bin";
- const struct firmware *firmware;
enum ucode_state ret;

- if (request_firmware(&firmware, fw_name, device)) {
- printk(KERN_ERR "microcode: failed to load file %s\n", fw_name);
+ if (firmware == NULL)
return UCODE_NFOUND;
- }

if (*(u32 *)firmware->data != UCODE_MAGIC) {
printk(KERN_ERR "microcode: invalid UCODE_MAGIC (0x%08x)\n",
@@ -318,8 +316,6 @@ static enum ucode_state request_microcode_fw(int cpu, struct device *device)

ret = generic_load_microcode(cpu, firmware->data, firmware->size);

- release_firmware(firmware);
-
return ret;
}

@@ -339,7 +335,21 @@ static void microcode_fini_cpu_amd(int cpu)
uci->mc = NULL;
}

+void init_microcode_amd(struct device *device)
+{
+ const char *fw_name = "amd-ucode/microcode_amd.bin";
+ if (request_firmware(&firmware, fw_name, device))
+ printk(KERN_ERR "microcode: failed to load file %s\n", fw_name);
+}
+
+void fini_microcode_amd(void)
+{
+ release_firmware(firmware);
+}
+
static struct microcode_ops microcode_amd_ops = {
+ .init = init_microcode_amd,
+ .fini = fini_microcode_amd,
.request_microcode_user = request_microcode_user,
.request_microcode_fw = request_microcode_fw,
.collect_cpu_info = collect_cpu_info_amd,
diff --git a/arch/x86/kernel/microcode_core.c b/arch/x86/kernel/microcode_core.c
index 2bcad39..230fb09 100644
--- a/arch/x86/kernel/microcode_core.c
+++ b/arch/x86/kernel/microcode_core.c
@@ -518,6 +518,9 @@ static int __init microcode_init(void)
return PTR_ERR(microcode_pdev);
}

+ if (microcode_ops->init)
+ microcode_ops->init(&microcode_pdev->dev);
+
get_online_cpus();
mutex_lock(&microcode_mutex);

@@ -561,6 +564,9 @@ static void __exit microcode_exit(void)

platform_device_unregister(microcode_pdev);

+ if (microcode_ops->fini)
+ microcode_ops->fini();
+
microcode_ops = NULL;

pr_info("Microcode Update Driver: v" MICROCODE_VERSION " removed.\n");
--
1.6.5.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/


dmitry.adamushko at gmail

Nov 10, 2009, 4:02 AM

Post #2 of 5 (103 views)
Permalink
Re: [PATCH 1/3] x86, ucode-amd: Load ucode-patches once and not separately fo each CPU [In reply to]

2009/11/10 Andreas Herrmann <herrmann.der.user [at] googlemail>:
> This also implies that corresponding log messages, e.g.
>
> platform microcode: firmware: requesting amd-ucode/microcode_amd.bin
>
> show up only once on module load and not when ucode is updated for
> each CPU.

I like it.

One remark : should we perhaps provide a means of reloading the cached
firmware? Or is the standard procedure to reload microcode.ko in case
a new firmware file has been installed?

btw., if we could safely assume that all the cpus after the ucode
upgrade share the same version/patch-level of ucode, we would be able
to cache a single ucode instance once and use it for all. I don't
recall anyone clearly stating that such multi-cpu-type systems can't
really exist.

e.g. is it possible to have AMD systems with cpus which differ from
each other not only by their revisions (patch_level)?


-- Dmitry
--
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/


clemens at ladisch

Nov 10, 2009, 11:51 PM

Post #3 of 5 (95 views)
Permalink
Re: [PATCH 1/3] x86, ucode-amd: Load ucode-patches once and not separately fo each CPU [In reply to]

Dmitry Adamushko wrote:
> btw., if we could safely assume that all the cpus after the ucode
> upgrade share the same version/patch-level of ucode, we would be able
> to cache a single ucode instance once and use it for all. I don't
> recall anyone clearly stating that such multi-cpu-type systems can't
> really exist.
>
> e.g. is it possible to have AMD systems with cpus which differ from
> each other not only by their revisions (patch_level)?

The Revision Guide for AMD Family 10h Processors (#41322) says, in
section "Mixed Silicon Support", that the Opteron B steppings can be
used with each other (DR-BA, DR-B2, DR-B3; CPUID 00100F2xh). Are
different steppings considered equivalent?


Clemens
--
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/


herrmann.der.user at googlemail

Nov 11, 2009, 3:27 AM

Post #4 of 5 (96 views)
Permalink
Re: [PATCH 1/3] x86, ucode-amd: Load ucode-patches once and not separately fo each CPU [In reply to]

On Wed, Nov 11, 2009 at 08:51:07AM +0100, Clemens Ladisch wrote:
> Dmitry Adamushko wrote:
> > btw., if we could safely assume that all the cpus after the ucode
> > upgrade share the same version/patch-level of ucode, we would be able
> > to cache a single ucode instance once and use it for all.

Hmm, I think all ucode-versions needed in a mixed silicon system need
to be cached. See below.

> > I don't recall anyone clearly stating that such multi-cpu-type
> > systems can't really exist.

> > e.g. is it possible to have AMD systems with cpus which differ from
> > each other not only by their revisions (patch_level)?

Mixed silicon is possible.

So at least in theory this could result in different patch_levels
because the required microcode is identified via processor revision
consisting of family/model/stepping.

> The Revision Guide for AMD Family 10h Processors (#41322) says, in
> section "Mixed Silicon Support", that the Opteron B steppings can be
> used with each other (DR-BA, DR-B2, DR-B3; CPUID 00100F2xh). Are
> different steppings considered equivalent?

The microcode to be loaded is identified by an Equivalent Processor
ID. The Equivalent Processor ID is determined with an equivalence
table which maps the processor revision IDs to Equivalent Processor
IDs.

Above revision B steppeings have different processor revision IDs:
(because the stepping differs)

00100F2Ah (DR-BA)
00100F22h (DR-B2)
00100F23h (DR-B3)

An example of an equivalence table is

0x00100F2A; 0x1020
0x00100F22; 0x1022
0x00100F23; 0x1022

This means when combining DR-BA and DR-B2 (or DR-B3) different ucode
gets installed for the two processors.


Regards,
Andreas
--
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/


herrmann.der.user at googlemail

Nov 12, 2009, 7:05 AM

Post #5 of 5 (89 views)
Permalink
Re: [PATCH 1/3] x86, ucode-amd: Load ucode-patches once and not separately fo each CPU [In reply to]

On Tue, Nov 10, 2009 at 01:02:39PM +0100, Dmitry Adamushko wrote:
> 2009/11/10 Andreas Herrmann <herrmann.der.user [at] googlemail>:
> > This also implies that corresponding log messages, e.g.
> >
> > platform microcode: firmware: requesting amd-ucode/microcode_amd.bin
> >
> > show up only once on module load and not when ucode is updated for
> > each CPU.
>
> I like it.
>
> One remark : should we perhaps provide a means of reloading the cached
> firmware?

I'll think about this.

> Or is the standard procedure to reload microcode.ko in case
> a new firmware file has been installed?

module reload will do so far.

(And I should ensure that microcode_amd is only provided if ucode
loader is compiled as module.)


Regards,
Andreas
--
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.