* [PATCH 0/3] x86 stuff for 4.14
@ 2017-07-24 10:12 Borislav Petkov
2017-07-24 10:12 ` [PATCH 1/3] x86/microcode/AMD: Free unneeded patch before exit from update_cache() Borislav Petkov
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: Borislav Petkov @ 2017-07-24 10:12 UTC (permalink / raw)
To: X86 ML; +Cc: LKML
From: Borislav Petkov <bp@suse.de>
Hi guys,
some fixes that got ready in the meantime. Yazen's goes to tip:ras/core
and the other two to tip:x86/microcode.
Thanks.
Borislav Petkov (1):
x86/microcode: Document the three loading methods
Shu Wang (1):
x86/microcode/AMD: Free unneeded patch before exit from update_cache()
Yazen Ghannam (1):
x86/mce/AMD: Allow any CPU to initialize smca_banks array
Documentation/x86/early-microcode.txt | 70 -----------------
Documentation/x86/microcode.txt | 137 ++++++++++++++++++++++++++++++++++
arch/x86/kernel/cpu/mcheck/mce_amd.c | 9 +--
arch/x86/kernel/cpu/microcode/amd.c | 5 +-
4 files changed, 143 insertions(+), 78 deletions(-)
delete mode 100644 Documentation/x86/early-microcode.txt
create mode 100644 Documentation/x86/microcode.txt
--
2.14.0.rc0
^ permalink raw reply [flat|nested] 12+ messages in thread* [PATCH 1/3] x86/microcode/AMD: Free unneeded patch before exit from update_cache() 2017-07-24 10:12 [PATCH 0/3] x86 stuff for 4.14 Borislav Petkov @ 2017-07-24 10:12 ` Borislav Petkov 2017-07-25 13:50 ` [tip:x86/microcode] " tip-bot for Shu Wang 2017-07-24 10:12 ` [PATCH 2/3] x86/microcode: Document the three loading methods Borislav Petkov 2017-07-24 10:12 ` [PATCH 3/3] x86/mce/AMD: Allow any CPU to initialize smca_banks array Borislav Petkov 2 siblings, 1 reply; 12+ messages in thread From: Borislav Petkov @ 2017-07-24 10:12 UTC (permalink / raw) To: X86 ML; +Cc: LKML From: Shu Wang <shuwang@redhat.com> verify_and_add_patch() allocates memory for a microcode patch and hands it down to be added to the cache of patches. However, if the cache already has the latest patch, the newly allocated one needs to be freed before returning. Do that. This issue has been found by kmemleak: unreferenced object 0xffff88010e780b40 (size 32): comm "bash", pid 860, jiffies 4294690939 (age 29.297s) backtrace: kmemleak_alloc kmem_cache_alloc_trace load_microcode_amd.isra.0 request_microcode_amd reload_store dev_attr_store sysfs_kf_write kernfs_fop_write __vfs_write vfs_write SyS_write do_syscall_64 return_from_SYSCALL_64 0xffffffffffffffff (gdb) list *0xffffffff81050d60 0xffffffff81050d60 is in load_microcode_amd (arch/x86/kernel/cpu/microcode/amd.c:616). which is this: patch = kzalloc(sizeof(*patch), GFP_KERNEL); --> if (!patch) { pr_err("Patch allocation failure.\n"); return -EINVAL; } Signed-off-by: Shu Wang <shuwang@redhat.com> Cc: chuhu@redhat.com Cc: liwang@redhat.com Cc: x86-ml <x86@kernel.org> Link: http://lkml.kernel.org/r/1500438083-15996-1-git-send-email-shuwang@redhat.com [ Rewrite commit message. ] Signed-off-by: Borislav Petkov <bp@suse.de> --- arch/x86/kernel/cpu/microcode/amd.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/microcode/amd.c b/arch/x86/kernel/cpu/microcode/amd.c index 21b185793c80..c6daec4bdba5 100644 --- a/arch/x86/kernel/cpu/microcode/amd.c +++ b/arch/x86/kernel/cpu/microcode/amd.c @@ -400,9 +400,12 @@ static void update_cache(struct ucode_patch *new_patch) list_for_each_entry(p, µcode_cache, plist) { if (p->equiv_cpu == new_patch->equiv_cpu) { - if (p->patch_id >= new_patch->patch_id) + if (p->patch_id >= new_patch->patch_id) { /* we already have the latest patch */ + kfree(new_patch->data); + kfree(new_patch); return; + } list_replace(&p->plist, &new_patch->plist); kfree(p->data); -- 2.14.0.rc0 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [tip:x86/microcode] x86/microcode/AMD: Free unneeded patch before exit from update_cache() 2017-07-24 10:12 ` [PATCH 1/3] x86/microcode/AMD: Free unneeded patch before exit from update_cache() Borislav Petkov @ 2017-07-25 13:50 ` tip-bot for Shu Wang 0 siblings, 0 replies; 12+ messages in thread From: tip-bot for Shu Wang @ 2017-07-25 13:50 UTC (permalink / raw) To: linux-tip-commits Cc: linux-kernel, hpa, mingo, bp, torvalds, peterz, tglx, shuwang Commit-ID: a99f03428faa2e53cce17aec0d636de760ec281a Gitweb: http://git.kernel.org/tip/a99f03428faa2e53cce17aec0d636de760ec281a Author: Shu Wang <shuwang@redhat.com> AuthorDate: Mon, 24 Jul 2017 12:12:26 +0200 Committer: Ingo Molnar <mingo@kernel.org> CommitDate: Tue, 25 Jul 2017 11:26:19 +0200 x86/microcode/AMD: Free unneeded patch before exit from update_cache() verify_and_add_patch() allocates memory for a microcode patch and hands it down to be added to the cache of patches. However, if the cache already has the latest patch, the newly allocated one needs to be freed before returning. Do that. This issue has been found by kmemleak: unreferenced object 0xffff88010e780b40 (size 32): comm "bash", pid 860, jiffies 4294690939 (age 29.297s) backtrace: kmemleak_alloc kmem_cache_alloc_trace load_microcode_amd.isra.0 request_microcode_amd reload_store dev_attr_store sysfs_kf_write kernfs_fop_write __vfs_write vfs_write SyS_write do_syscall_64 return_from_SYSCALL_64 0xffffffffffffffff (gdb) list *0xffffffff81050d60 0xffffffff81050d60 is in load_microcode_amd (arch/x86/kernel/cpu/microcode/amd.c:616). which is this: patch = kzalloc(sizeof(*patch), GFP_KERNEL); --> if (!patch) { pr_err("Patch allocation failure.\n"); return -EINVAL; } Signed-off-by: Shu Wang <shuwang@redhat.com> [ Rewrite commit message. ] Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: chuhu@redhat.com Cc: liwang@redhat.com Link: http://lkml.kernel.org/r/20170724101228.17326-2-bp@alien8.de Signed-off-by: Ingo Molnar <mingo@kernel.org> --- arch/x86/kernel/cpu/microcode/amd.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/microcode/amd.c b/arch/x86/kernel/cpu/microcode/amd.c index 21b1857..c6daec4 100644 --- a/arch/x86/kernel/cpu/microcode/amd.c +++ b/arch/x86/kernel/cpu/microcode/amd.c @@ -400,9 +400,12 @@ static void update_cache(struct ucode_patch *new_patch) list_for_each_entry(p, µcode_cache, plist) { if (p->equiv_cpu == new_patch->equiv_cpu) { - if (p->patch_id >= new_patch->patch_id) + if (p->patch_id >= new_patch->patch_id) { /* we already have the latest patch */ + kfree(new_patch->data); + kfree(new_patch); return; + } list_replace(&p->plist, &new_patch->plist); kfree(p->data); ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH 2/3] x86/microcode: Document the three loading methods 2017-07-24 10:12 [PATCH 0/3] x86 stuff for 4.14 Borislav Petkov 2017-07-24 10:12 ` [PATCH 1/3] x86/microcode/AMD: Free unneeded patch before exit from update_cache() Borislav Petkov @ 2017-07-24 10:12 ` Borislav Petkov 2017-07-25 13:51 ` [tip:x86/microcode] " tip-bot for Borislav Petkov 2017-07-24 10:12 ` [PATCH 3/3] x86/mce/AMD: Allow any CPU to initialize smca_banks array Borislav Petkov 2 siblings, 1 reply; 12+ messages in thread From: Borislav Petkov @ 2017-07-24 10:12 UTC (permalink / raw) To: X86 ML; +Cc: LKML From: Borislav Petkov <bp@suse.de> Paul Menzel <pmenzel@molgen.mpg.de> asked recently how to load microcode on a system and I realized that we don't really have all the methods written down somewhere. Do that, so people can go and look them up. Signed-off-by: Borislav Petkov <bp@suse.de> --- Documentation/x86/early-microcode.txt | 70 ----------------- Documentation/x86/microcode.txt | 137 ++++++++++++++++++++++++++++++++++ 2 files changed, 137 insertions(+), 70 deletions(-) delete mode 100644 Documentation/x86/early-microcode.txt create mode 100644 Documentation/x86/microcode.txt diff --git a/Documentation/x86/early-microcode.txt b/Documentation/x86/early-microcode.txt deleted file mode 100644 index 07749e7f3d50..000000000000 --- a/Documentation/x86/early-microcode.txt +++ /dev/null @@ -1,70 +0,0 @@ -Early load microcode -==================== -By Fenghua Yu <fenghua.yu@intel.com> - -Kernel can update microcode in early phase of boot time. Loading microcode early -can fix CPU issues before they are observed during kernel boot time. - -Microcode is stored in an initrd file. The microcode is read from the initrd -file and loaded to CPUs during boot time. - -The format of the combined initrd image is microcode in cpio format followed by -the initrd image (maybe compressed). Kernel parses the combined initrd image -during boot time. The microcode file in cpio name space is: -on Intel: kernel/x86/microcode/GenuineIntel.bin -on AMD : kernel/x86/microcode/AuthenticAMD.bin - -During BSP boot (before SMP starts), if the kernel finds the microcode file in -the initrd file, it parses the microcode and saves matching microcode in memory. -If matching microcode is found, it will be uploaded in BSP and later on in all -APs. - -The cached microcode patch is applied when CPUs resume from a sleep state. - -There are two legacy user space interfaces to load microcode, either through -/dev/cpu/microcode or through /sys/devices/system/cpu/microcode/reload file -in sysfs. - -In addition to these two legacy methods, the early loading method described -here is the third method with which microcode can be uploaded to a system's -CPUs. - -The following example script shows how to generate a new combined initrd file in -/boot/initrd-3.5.0.ucode.img with original microcode microcode.bin and -original initrd image /boot/initrd-3.5.0.img. - -mkdir initrd -cd initrd -mkdir -p kernel/x86/microcode -cp ../microcode.bin kernel/x86/microcode/GenuineIntel.bin (or AuthenticAMD.bin) -find . | cpio -o -H newc >../ucode.cpio -cd .. -cat ucode.cpio /boot/initrd-3.5.0.img >/boot/initrd-3.5.0.ucode.img - -Builtin microcode -================= - -We can also load builtin microcode supplied through the regular firmware -builtin method CONFIG_FIRMWARE_IN_KERNEL. Only 64-bit is currently -supported. - -Here's an example: - -CONFIG_FIRMWARE_IN_KERNEL=y -CONFIG_EXTRA_FIRMWARE="intel-ucode/06-3a-09 amd-ucode/microcode_amd_fam15h.bin" -CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware" - -This basically means, you have the following tree structure locally: - -/lib/firmware/ -|-- amd-ucode -... -| |-- microcode_amd_fam15h.bin -... -|-- intel-ucode -... -| |-- 06-3a-09 -... - -so that the build system can find those files and integrate them into -the final kernel image. The early loader finds them and applies them. diff --git a/Documentation/x86/microcode.txt b/Documentation/x86/microcode.txt new file mode 100644 index 000000000000..8d655afb0436 --- /dev/null +++ b/Documentation/x86/microcode.txt @@ -0,0 +1,137 @@ + The Linux Microcode Loader + +Authors: Fenghua Yu <fenghua.yu@intel.com> + Borislav Petkov <bp@suse.de> + +The kernel has a x86 microcode loading facility which is supposed to +provide microcode loading methods in the OS. Potential use cases are +updating the microcode on platforms beyond the OEM End-Of-Life support, +and updating the microcode on long-running systems without rebooting. + +The loader supports three loading methods: + +1. Early load microcode +======================= + +The kernel can update microcode very early during boot. Loading +microcode early can fix CPU issues before they are observed during +kernel boot time. + +The microcode is stored in an initrd file. During boot, it is read from +it and loaded into the CPU cores. + +The format of the combined initrd image is microcode in (uncompressed) +cpio format followed by the (possibly compressed) initrd image. The +loader parses the combined initrd image during boot. + +The microcode files in cpio name space are: + +on Intel: kernel/x86/microcode/GenuineIntel.bin +on AMD : kernel/x86/microcode/AuthenticAMD.bin + +During BSP (BootStrapping Processor) boot (pre-SMP), the kernel +scans the microcode file in the initrd. If microcode matching the +CPU is found, it will be applied in the BSP and later on in all APs +(Application Processors). + +The loader also saves the matching microcode for the CPU in memory. +Thus, the cached microcode patch is applied when CPUs resume from a +sleep state. + +Here's a crude example how to prepare an initrd with microcode (this is +normally done automatically by the distribution, when recreating the +initrd, so you don't really have to do it yourself. It is documented +here for future reference only). + +--- + #!/bin/bash + + if [ -z "$1" ]; then + echo "You need to supply an initrd file" + exit 1 + fi + + INITRD="$1" + + DSTDIR=kernel/x86/microcode + TMPDIR=/tmp/initrd + + rm -rf $TMPDIR + + mkdir $TMPDIR + cd $TMPDIR + mkdir -p $DSTDIR + + if [ -d /lib/firmware/amd-ucode ]; then + cat /lib/firmware/amd-ucode/microcode_amd*.bin > $DSTDIR/AuthenticAMD.bin + fi + + if [ -d /lib/firmware/intel-ucode ]; then + cat /lib/firmware/intel-ucode/* > $DSTDIR/GenuineIntel.bin + fi + + find . | cpio -o -H newc >../ucode.cpio + cd .. + mv $INITRD $INITRD.orig + cat ucode.cpio $INITRD.orig > $INITRD + + rm -rf $TMPDIR +--- + +The system needs to have the microcode packages installed into +/lib/firmware or you need to fixup the paths above if yours are +somewhere else and/or you've downloaded them directly from the processor +vendor's site. + +2. Late loading +=============== + +There are two legacy user space interfaces to load microcode, either through +/dev/cpu/microcode or through /sys/devices/system/cpu/microcode/reload file +in sysfs. + +The /dev/cpu/microcode method is deprecated because it needs a special +userspace tool for that. + +The easier method is simply installing the microcode packages your distro +supplies and running: + +# echo 1 > /sys/devices/system/cpu/microcode/reload + +as root. + +The loading mechanism looks for microcode blobs in +/lib/firmware/{intel-ucode,amd-ucode}. The default distro installation +packages already put them there. + +3. Builtin microcode +==================== + +The loader supports also loading of a builtin microcode supplied through +the regular firmware builtin method CONFIG_FIRMWARE_IN_KERNEL. Only +64-bit is currently supported. + +Here's an example: + +CONFIG_FIRMWARE_IN_KERNEL=y +CONFIG_EXTRA_FIRMWARE="intel-ucode/06-3a-09 amd-ucode/microcode_amd_fam15h.bin" +CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware" + +This basically means, you have the following tree structure locally: + +/lib/firmware/ +|-- amd-ucode +... +| |-- microcode_amd_fam15h.bin +... +|-- intel-ucode +... +| |-- 06-3a-09 +... + +so that the build system can find those files and integrate them into +the final kernel image. The early loader finds them and applies them. + +Needless to say, this method is not the most flexible one because it +requires rebuilding the kernel each time updated microcode from the CPU +vendor is available. -- 2.14.0.rc0 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [tip:x86/microcode] x86/microcode: Document the three loading methods 2017-07-24 10:12 ` [PATCH 2/3] x86/microcode: Document the three loading methods Borislav Petkov @ 2017-07-25 13:51 ` tip-bot for Borislav Petkov 2017-08-04 11:24 ` Paul Menzel 0 siblings, 1 reply; 12+ messages in thread From: tip-bot for Borislav Petkov @ 2017-07-25 13:51 UTC (permalink / raw) To: linux-tip-commits Cc: peterz, mingo, bp, torvalds, tglx, pmenzel, hpa, linux-kernel Commit-ID: 0e3258753f8183c63bf68bd274d2cc7e71e5f402 Gitweb: http://git.kernel.org/tip/0e3258753f8183c63bf68bd274d2cc7e71e5f402 Author: Borislav Petkov <bp@suse.de> AuthorDate: Mon, 24 Jul 2017 12:12:27 +0200 Committer: Ingo Molnar <mingo@kernel.org> CommitDate: Tue, 25 Jul 2017 11:26:24 +0200 x86/microcode: Document the three loading methods Paul Menzel recently asked how to load microcode on a system and I realized that we don't really have all the methods written down somewhere. Do that, so people can go and look them up. Reported-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20170724101228.17326-3-bp@alien8.de [ Fix whitespace noise in the new description. ] Signed-off-by: Ingo Molnar <mingo@kernel.org> --- Documentation/x86/early-microcode.txt | 70 ----------------- Documentation/x86/microcode.txt | 137 ++++++++++++++++++++++++++++++++++ 2 files changed, 137 insertions(+), 70 deletions(-) diff --git a/Documentation/x86/early-microcode.txt b/Documentation/x86/early-microcode.txt deleted file mode 100644 index 07749e7..0000000 --- a/Documentation/x86/early-microcode.txt +++ /dev/null @@ -1,70 +0,0 @@ -Early load microcode -==================== -By Fenghua Yu <fenghua.yu@intel.com> - -Kernel can update microcode in early phase of boot time. Loading microcode early -can fix CPU issues before they are observed during kernel boot time. - -Microcode is stored in an initrd file. The microcode is read from the initrd -file and loaded to CPUs during boot time. - -The format of the combined initrd image is microcode in cpio format followed by -the initrd image (maybe compressed). Kernel parses the combined initrd image -during boot time. The microcode file in cpio name space is: -on Intel: kernel/x86/microcode/GenuineIntel.bin -on AMD : kernel/x86/microcode/AuthenticAMD.bin - -During BSP boot (before SMP starts), if the kernel finds the microcode file in -the initrd file, it parses the microcode and saves matching microcode in memory. -If matching microcode is found, it will be uploaded in BSP and later on in all -APs. - -The cached microcode patch is applied when CPUs resume from a sleep state. - -There are two legacy user space interfaces to load microcode, either through -/dev/cpu/microcode or through /sys/devices/system/cpu/microcode/reload file -in sysfs. - -In addition to these two legacy methods, the early loading method described -here is the third method with which microcode can be uploaded to a system's -CPUs. - -The following example script shows how to generate a new combined initrd file in -/boot/initrd-3.5.0.ucode.img with original microcode microcode.bin and -original initrd image /boot/initrd-3.5.0.img. - -mkdir initrd -cd initrd -mkdir -p kernel/x86/microcode -cp ../microcode.bin kernel/x86/microcode/GenuineIntel.bin (or AuthenticAMD.bin) -find . | cpio -o -H newc >../ucode.cpio -cd .. -cat ucode.cpio /boot/initrd-3.5.0.img >/boot/initrd-3.5.0.ucode.img - -Builtin microcode -================= - -We can also load builtin microcode supplied through the regular firmware -builtin method CONFIG_FIRMWARE_IN_KERNEL. Only 64-bit is currently -supported. - -Here's an example: - -CONFIG_FIRMWARE_IN_KERNEL=y -CONFIG_EXTRA_FIRMWARE="intel-ucode/06-3a-09 amd-ucode/microcode_amd_fam15h.bin" -CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware" - -This basically means, you have the following tree structure locally: - -/lib/firmware/ -|-- amd-ucode -... -| |-- microcode_amd_fam15h.bin -... -|-- intel-ucode -... -| |-- 06-3a-09 -... - -so that the build system can find those files and integrate them into -the final kernel image. The early loader finds them and applies them. diff --git a/Documentation/x86/microcode.txt b/Documentation/x86/microcode.txt new file mode 100644 index 0000000..f57e1b4 --- /dev/null +++ b/Documentation/x86/microcode.txt @@ -0,0 +1,137 @@ + The Linux Microcode Loader + +Authors: Fenghua Yu <fenghua.yu@intel.com> + Borislav Petkov <bp@suse.de> + +The kernel has a x86 microcode loading facility which is supposed to +provide microcode loading methods in the OS. Potential use cases are +updating the microcode on platforms beyond the OEM End-Of-Life support, +and updating the microcode on long-running systems without rebooting. + +The loader supports three loading methods: + +1. Early load microcode +======================= + +The kernel can update microcode very early during boot. Loading +microcode early can fix CPU issues before they are observed during +kernel boot time. + +The microcode is stored in an initrd file. During boot, it is read from +it and loaded into the CPU cores. + +The format of the combined initrd image is microcode in (uncompressed) +cpio format followed by the (possibly compressed) initrd image. The +loader parses the combined initrd image during boot. + +The microcode files in cpio name space are: + +on Intel: kernel/x86/microcode/GenuineIntel.bin +on AMD : kernel/x86/microcode/AuthenticAMD.bin + +During BSP (BootStrapping Processor) boot (pre-SMP), the kernel +scans the microcode file in the initrd. If microcode matching the +CPU is found, it will be applied in the BSP and later on in all APs +(Application Processors). + +The loader also saves the matching microcode for the CPU in memory. +Thus, the cached microcode patch is applied when CPUs resume from a +sleep state. + +Here's a crude example how to prepare an initrd with microcode (this is +normally done automatically by the distribution, when recreating the +initrd, so you don't really have to do it yourself. It is documented +here for future reference only). + +--- + #!/bin/bash + + if [ -z "$1" ]; then + echo "You need to supply an initrd file" + exit 1 + fi + + INITRD="$1" + + DSTDIR=kernel/x86/microcode + TMPDIR=/tmp/initrd + + rm -rf $TMPDIR + + mkdir $TMPDIR + cd $TMPDIR + mkdir -p $DSTDIR + + if [ -d /lib/firmware/amd-ucode ]; then + cat /lib/firmware/amd-ucode/microcode_amd*.bin > $DSTDIR/AuthenticAMD.bin + fi + + if [ -d /lib/firmware/intel-ucode ]; then + cat /lib/firmware/intel-ucode/* > $DSTDIR/GenuineIntel.bin + fi + + find . | cpio -o -H newc >../ucode.cpio + cd .. + mv $INITRD $INITRD.orig + cat ucode.cpio $INITRD.orig > $INITRD + + rm -rf $TMPDIR +--- + +The system needs to have the microcode packages installed into +/lib/firmware or you need to fixup the paths above if yours are +somewhere else and/or you've downloaded them directly from the processor +vendor's site. + +2. Late loading +=============== + +There are two legacy user space interfaces to load microcode, either through +/dev/cpu/microcode or through /sys/devices/system/cpu/microcode/reload file +in sysfs. + +The /dev/cpu/microcode method is deprecated because it needs a special +userspace tool for that. + +The easier method is simply installing the microcode packages your distro +supplies and running: + +# echo 1 > /sys/devices/system/cpu/microcode/reload + +as root. + +The loading mechanism looks for microcode blobs in +/lib/firmware/{intel-ucode,amd-ucode}. The default distro installation +packages already put them there. + +3. Builtin microcode +==================== + +The loader supports also loading of a builtin microcode supplied through +the regular firmware builtin method CONFIG_FIRMWARE_IN_KERNEL. Only +64-bit is currently supported. + +Here's an example: + +CONFIG_FIRMWARE_IN_KERNEL=y +CONFIG_EXTRA_FIRMWARE="intel-ucode/06-3a-09 amd-ucode/microcode_amd_fam15h.bin" +CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware" + +This basically means, you have the following tree structure locally: + +/lib/firmware/ +|-- amd-ucode +... +| |-- microcode_amd_fam15h.bin +... +|-- intel-ucode +... +| |-- 06-3a-09 +... + +so that the build system can find those files and integrate them into +the final kernel image. The early loader finds them and applies them. + +Needless to say, this method is not the most flexible one because it +requires rebuilding the kernel each time updated microcode from the CPU +vendor is available. ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [tip:x86/microcode] x86/microcode: Document the three loading methods 2017-07-25 13:51 ` [tip:x86/microcode] " tip-bot for Borislav Petkov @ 2017-08-04 11:24 ` Paul Menzel 2017-08-05 6:15 ` Borislav Petkov 0 siblings, 1 reply; 12+ messages in thread From: Paul Menzel @ 2017-08-04 11:24 UTC (permalink / raw) To: hpa, bp, torvalds, tglx, linux-kernel, mingo, peterz Dear Borislav, Hopefully, it’s alright to reply to this message. I am sorry for the late reply. On 07/25/17 15:51, tip-bot for Borislav Petkov wrote: > Commit-ID: 0e3258753f8183c63bf68bd274d2cc7e71e5f402 > Gitweb: http://git.kernel.org/tip/0e3258753f8183c63bf68bd274d2cc7e71e5f402 Could you the script(?) please be updated to use HTTPS URLs? > Author: Borislav Petkov <bp@suse.de> > AuthorDate: Mon, 24 Jul 2017 12:12:27 +0200 > Committer: Ingo Molnar <mingo@kernel.org> > CommitDate: Tue, 25 Jul 2017 11:26:24 +0200 > > x86/microcode: Document the three loading methods > > Paul Menzel recently asked how to load microcode on a system and I realized > that we don't really have all the methods written down somewhere. > > Do that, so people can go and look them up. > > Reported-by: Paul Menzel <pmenzel@molgen.mpg.de> > Signed-off-by: Borislav Petkov <bp@suse.de> > Cc: Linus Torvalds <torvalds@linux-foundation.org> > Cc: Peter Zijlstra <peterz@infradead.org> > Cc: Thomas Gleixner <tglx@linutronix.de> > Link: http://lkml.kernel.org/r/20170724101228.17326-3-bp@alien8.de Here to please HTTPS. (It’s even using HTTP/2 then. Kudos to the administrators.) > [ Fix whitespace noise in the new description. ] > Signed-off-by: Ingo Molnar <mingo@kernel.org> > --- > Documentation/x86/early-microcode.txt | 70 ----------------- > Documentation/x86/microcode.txt | 137 ++++++++++++++++++++++++++++++++++ > 2 files changed, 137 insertions(+), 70 deletions(-) > > diff --git a/Documentation/x86/early-microcode.txt b/Documentation/x86/early-microcode.txt > deleted file mode 100644 > index 07749e7..0000000 > --- a/Documentation/x86/early-microcode.txt […] > --- /dev/null > +++ b/Documentation/x86/microcode.txt > @@ -0,0 +1,137 @@ > + The Linux Microcode Loader > + > +Authors: Fenghua Yu <fenghua.yu@intel.com> > + Borislav Petkov <bp@suse.de> > + > +The kernel has a x86 microcode loading facility which is supposed to > +provide microcode loading methods in the OS. Potential use cases are > +updating the microcode on platforms beyond the OEM End-Of-Life support, > +and updating the microcode on long-running systems without rebooting. > + > +The loader supports three loading methods: > + > +1. Early load microcode > +======================= > + > +The kernel can update microcode very early during boot. Loading > +microcode early can fix CPU issues before they are observed during > +kernel boot time. > + > +The microcode is stored in an initrd file. During boot, it is read from > +it and loaded into the CPU cores. > + > +The format of the combined initrd image is microcode in (uncompressed) > +cpio format followed by the (possibly compressed) initrd image. The > +loader parses the combined initrd image during boot. > + > +The microcode files in cpio name space are: > + > +on Intel: kernel/x86/microcode/GenuineIntel.bin > +on AMD : kernel/x86/microcode/AuthenticAMD.bin > + > +During BSP (BootStrapping Processor) boot (pre-SMP), the kernel > +scans the microcode file in the initrd. If microcode matching the > +CPU is found, it will be applied in the BSP and later on in all APs > +(Application Processors). > + > +The loader also saves the matching microcode for the CPU in memory. > +Thus, the cached microcode patch is applied when CPUs resume from a > +sleep state. > + > +Here's a crude example how to prepare an initrd with microcode (this is > +normally done automatically by the distribution, when recreating the > +initrd, so you don't really have to do it yourself. It is documented > +here for future reference only). > + > +--- > + #!/bin/bash > + > + if [ -z "$1" ]; then > + echo "You need to supply an initrd file" > + exit 1 > + fi > + > + INITRD="$1" > + > + DSTDIR=kernel/x86/microcode > + TMPDIR=/tmp/initrd > + > + rm -rf $TMPDIR > + > + mkdir $TMPDIR > + cd $TMPDIR > + mkdir -p $DSTDIR > + > + if [ -d /lib/firmware/amd-ucode ]; then > + cat /lib/firmware/amd-ucode/microcode_amd*.bin > $DSTDIR/AuthenticAMD.bin > + fi > + > + if [ -d /lib/firmware/intel-ucode ]; then > + cat /lib/firmware/intel-ucode/* > $DSTDIR/GenuineIntel.bin > + fi > + > + find . | cpio -o -H newc >../ucode.cpio > + cd .. > + mv $INITRD $INITRD.orig > + cat ucode.cpio $INITRD.orig > $INITRD > + > + rm -rf $TMPDIR > +--- Maybe it could be added, that certain bootloaders like GRUB allow to specify several `initrd` images. So you wouldn’t need to concatenate the file [1]. > + > +The system needs to have the microcode packages installed into > +/lib/firmware or you need to fixup the paths above if yours are The verb *fix up* is spelled with a space. > +somewhere else and/or you've downloaded them directly from the processor > +vendor's site. > + > +2. Late loading > +=============== > + > +There are two legacy user space interfaces to load microcode, either through > +/dev/cpu/microcode or through /sys/devices/system/cpu/microcode/reload file > +in sysfs. The *legacy* confuses me a little. Is it because `/sys` is used? > +The /dev/cpu/microcode method is deprecated because it needs a special > +userspace tool for that. > + > +The easier method is simply installing the microcode packages your distro > +supplies and running: > + > +# echo 1 > /sys/devices/system/cpu/microcode/reload > + > +as root. > + > +The loading mechanism looks for microcode blobs in > +/lib/firmware/{intel-ucode,amd-ucode}. The default distro installation > +packages already put them there. > + > +3. Builtin microcode > +==================== > + > +The loader supports also loading of a builtin microcode supplied through > +the regular firmware builtin method CONFIG_FIRMWARE_IN_KERNEL. Only > +64-bit is currently supported. > + > +Here's an example: > + > +CONFIG_FIRMWARE_IN_KERNEL=y > +CONFIG_EXTRA_FIRMWARE="intel-ucode/06-3a-09 amd-ucode/microcode_amd_fam15h.bin" > +CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware" > + > +This basically means, you have the following tree structure locally: > + > +/lib/firmware/ > +|-- amd-ucode > +... > +| |-- microcode_amd_fam15h.bin > +... > +|-- intel-ucode > +... > +| |-- 06-3a-09 > +... > + > +so that the build system can find those files and integrate them into > +the final kernel image. The early loader finds them and applies them. > + > +Needless to say, this method is not the most flexible one because it > +requires rebuilding the kernel each time updated microcode from the CPU > +vendor is available. Thank you again for improving and extending the documentation for people like me. Kind regards, Paul [1] https://wiki.gentoo.org/wiki/Intel_microcode#Grub_2.x ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [tip:x86/microcode] x86/microcode: Document the three loading methods 2017-08-04 11:24 ` Paul Menzel @ 2017-08-05 6:15 ` Borislav Petkov 0 siblings, 0 replies; 12+ messages in thread From: Borislav Petkov @ 2017-08-05 6:15 UTC (permalink / raw) To: Paul Menzel; +Cc: hpa, torvalds, tglx, linux-kernel, mingo, peterz On Fri, Aug 04, 2017 at 01:24:02PM +0200, Paul Menzel wrote: > > Gitweb: http://git.kernel.org/tip/0e3258753f8183c63bf68bd274d2cc7e71e5f402 > > Could you the script(?) please be updated to use HTTPS URLs? tip guys? > Maybe it could be added, that certain bootloaders like GRUB allow to specify > several `initrd` images. So you wouldn’t need to concatenate the file [1]. So this is the simplest script possible just to show the basic steps that are required. Any treatise of what some bootloaders do is out of scope as then I'm going to have to maintain a full-fledged script (there will be other people saying, but but, on my system... ) which is going to be pointless - distros are free to create the initrd they way they see best. This script is an example only and the bare minimum at that. > The *legacy* confuses me a little. Is it because `/sys` is used? They're legacy because they're the older methods and people should try to avoid them and concentrate on the early, initrd loading. Thanks. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH 3/3] x86/mce/AMD: Allow any CPU to initialize smca_banks array 2017-07-24 10:12 [PATCH 0/3] x86 stuff for 4.14 Borislav Petkov 2017-07-24 10:12 ` [PATCH 1/3] x86/microcode/AMD: Free unneeded patch before exit from update_cache() Borislav Petkov 2017-07-24 10:12 ` [PATCH 2/3] x86/microcode: Document the three loading methods Borislav Petkov @ 2017-07-24 10:12 ` Borislav Petkov 2017-07-25 13:51 ` tip-bot for Borislav Petkov 2017-07-25 13:55 ` tip-bot for Borislav Petkov 2 siblings, 2 replies; 12+ messages in thread From: Borislav Petkov @ 2017-07-24 10:12 UTC (permalink / raw) To: X86 ML; +Cc: LKML From: Yazen Ghannam <yazen.ghannam@amd.com> Current SMCA implementations have the same banks on each CPU with the non-core banks only visible to a "master thread" on each die. Practically, this means the smca_banks array, which describes the banks, only needs to be populated once by a single master thread. CPU 0 seemed like a good candidate to do the populating. However, it's possible that CPU 0 is not enabled in which case the smca_banks array won't be populated. Rather than try to figure out another master thread to do the populating, we should just allow any CPU to populate the array. Drop the CPU 0 check and return early if the bank was already initialized. Also, drop the WARNing about an already initialized bank, since this will be a common, expected occurrence. The smca_banks array is only populated at boot time and CPUs are brought online sequentially. So there's no need for locking around the array. If the first CPU up is a master thread, then it will populate the array with all banks, core and non-core. Every CPU afterwards will return early. If the first CPU up is not a master thread, then it will populate the array with all core banks. The first CPU afterwards that is a master thread will skip populating the core banks and continue populating the non-core banks. Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Acked-by: Jack Miller <jack@codezen.org> Cc: Tony Luck <tony.luck@intel.com> Cc: linux-edac <linux-edac@vger.kernel.org> Cc: x86-ml <x86@kernel.org> Link: http://lkml.kernel.org/r/1498759708-27680-1-git-send-email-Yazen.Ghannam@amd.com Signed-off-by: Borislav Petkov <bp@suse.de> --- arch/x86/kernel/cpu/mcheck/mce_amd.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/arch/x86/kernel/cpu/mcheck/mce_amd.c b/arch/x86/kernel/cpu/mcheck/mce_amd.c index 9e314bcf67cc..5ce1a5689162 100644 --- a/arch/x86/kernel/cpu/mcheck/mce_amd.c +++ b/arch/x86/kernel/cpu/mcheck/mce_amd.c @@ -201,8 +201,8 @@ static void smca_configure(unsigned int bank, unsigned int cpu) wrmsr(smca_config, low, high); } - /* Collect bank_info using CPU 0 for now. */ - if (cpu) + /* Return early if this bank was already initialized. */ + if (smca_banks[bank].hwid) return; if (rdmsr_safe_on_cpu(cpu, MSR_AMD64_SMCA_MCx_IPID(bank), &low, &high)) { @@ -216,11 +216,6 @@ static void smca_configure(unsigned int bank, unsigned int cpu) for (i = 0; i < ARRAY_SIZE(smca_hwid_mcatypes); i++) { s_hwid = &smca_hwid_mcatypes[i]; if (hwid_mcatype == s_hwid->hwid_mcatype) { - - WARN(smca_banks[bank].hwid, - "Bank %s already initialized!\n", - smca_get_name(s_hwid->bank_type)); - smca_banks[bank].hwid = s_hwid; smca_banks[bank].id = low; smca_banks[bank].sysfs_id = s_hwid->count++; -- 2.14.0.rc0 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [tip:ras/core] x86/mce/AMD: Allow any CPU to initialize the smca_banks array @ 2017-07-25 13:51 ` tip-bot for Borislav Petkov 0 siblings, 0 replies; 12+ messages in thread From: tip-bot for Yazen Ghannam @ 2017-07-25 13:51 UTC (permalink / raw) To: linux-tip-commits Cc: linux-edac, linux-kernel, hpa, bp, tony.luck, mingo, torvalds, yazen.ghannam, jack, peterz, tglx Commit-ID: df7ce2c4bfc9660be86624b647034160c0585328 Gitweb: http://git.kernel.org/tip/df7ce2c4bfc9660be86624b647034160c0585328 Author: Yazen Ghannam <yazen.ghannam@amd.com> AuthorDate: Mon, 24 Jul 2017 12:12:28 +0200 Committer: Ingo Molnar <mingo@kernel.org> CommitDate: Tue, 25 Jul 2017 11:26:47 +0200 x86/mce/AMD: Allow any CPU to initialize the smca_banks array Current SMCA implementations have the same banks on each CPU with the non-core banks only visible to a "master thread" on each die. Practically, this means the smca_banks array, which describes the banks, only needs to be populated once by a single master thread. CPU 0 seemed like a good candidate to do the populating. However, it's possible that CPU 0 is not enabled in which case the smca_banks array won't be populated. Rather than try to figure out another master thread to do the populating, we should just allow any CPU to populate the array. Drop the CPU 0 check and return early if the bank was already initialized. Also, drop the WARNing about an already initialized bank, since this will be a common, expected occurrence. The smca_banks array is only populated at boot time and CPUs are brought online sequentially. So there's no need for locking around the array. If the first CPU up is a master thread, then it will populate the array with all banks, core and non-core. Every CPU afterwards will return early. If the first CPU up is not a master thread, then it will populate the array with all core banks. The first CPU afterwards that is a master thread will skip populating the core banks and continue populating the non-core banks. Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Jack Miller <jack@codezen.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tony Luck <tony.luck@intel.com> Cc: linux-edac <linux-edac@vger.kernel.org> Link: http://lkml.kernel.org/r/20170724101228.17326-4-bp@alien8.de Signed-off-by: Ingo Molnar <mingo@kernel.org> --- arch/x86/kernel/cpu/mcheck/mce_amd.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/arch/x86/kernel/cpu/mcheck/mce_amd.c b/arch/x86/kernel/cpu/mcheck/mce_amd.c index 9e314bc..5ce1a56 100644 --- a/arch/x86/kernel/cpu/mcheck/mce_amd.c +++ b/arch/x86/kernel/cpu/mcheck/mce_amd.c @@ -201,8 +201,8 @@ static void smca_configure(unsigned int bank, unsigned int cpu) wrmsr(smca_config, low, high); } - /* Collect bank_info using CPU 0 for now. */ - if (cpu) + /* Return early if this bank was already initialized. */ + if (smca_banks[bank].hwid) return; if (rdmsr_safe_on_cpu(cpu, MSR_AMD64_SMCA_MCx_IPID(bank), &low, &high)) { @@ -216,11 +216,6 @@ static void smca_configure(unsigned int bank, unsigned int cpu) for (i = 0; i < ARRAY_SIZE(smca_hwid_mcatypes); i++) { s_hwid = &smca_hwid_mcatypes[i]; if (hwid_mcatype == s_hwid->hwid_mcatype) { - - WARN(smca_banks[bank].hwid, - "Bank %s already initialized!\n", - smca_get_name(s_hwid->bank_type)); - smca_banks[bank].hwid = s_hwid; smca_banks[bank].id = low; smca_banks[bank].sysfs_id = s_hwid->count++; ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [tip:ras/core] x86/mce/AMD: Allow any CPU to initialize the smca_banks array @ 2017-07-25 13:51 ` tip-bot for Borislav Petkov 0 siblings, 0 replies; 12+ messages in thread From: tip-bot for Borislav Petkov @ 2017-07-25 13:51 UTC (permalink / raw) To: linux-tip-commits Cc: linux-edac, linux-kernel, hpa, bp, tony.luck, mingo, torvalds, yazen.ghannam, jack, peterz, tglx Commit-ID: df7ce2c4bfc9660be86624b647034160c0585328 Gitweb: http://git.kernel.org/tip/df7ce2c4bfc9660be86624b647034160c0585328 Author: Yazen Ghannam <yazen.ghannam@amd.com> AuthorDate: Mon, 24 Jul 2017 12:12:28 +0200 Committer: Ingo Molnar <mingo@kernel.org> CommitDate: Tue, 25 Jul 2017 11:26:47 +0200 x86/mce/AMD: Allow any CPU to initialize the smca_banks array Current SMCA implementations have the same banks on each CPU with the non-core banks only visible to a "master thread" on each die. Practically, this means the smca_banks array, which describes the banks, only needs to be populated once by a single master thread. CPU 0 seemed like a good candidate to do the populating. However, it's possible that CPU 0 is not enabled in which case the smca_banks array won't be populated. Rather than try to figure out another master thread to do the populating, we should just allow any CPU to populate the array. Drop the CPU 0 check and return early if the bank was already initialized. Also, drop the WARNing about an already initialized bank, since this will be a common, expected occurrence. The smca_banks array is only populated at boot time and CPUs are brought online sequentially. So there's no need for locking around the array. If the first CPU up is a master thread, then it will populate the array with all banks, core and non-core. Every CPU afterwards will return early. If the first CPU up is not a master thread, then it will populate the array with all core banks. The first CPU afterwards that is a master thread will skip populating the core banks and continue populating the non-core banks. Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Jack Miller <jack@codezen.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tony Luck <tony.luck@intel.com> Cc: linux-edac <linux-edac@vger.kernel.org> Link: http://lkml.kernel.org/r/20170724101228.17326-4-bp@alien8.de Signed-off-by: Ingo Molnar <mingo@kernel.org> --- arch/x86/kernel/cpu/mcheck/mce_amd.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-edac" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/arch/x86/kernel/cpu/mcheck/mce_amd.c b/arch/x86/kernel/cpu/mcheck/mce_amd.c index 9e314bc..5ce1a56 100644 --- a/arch/x86/kernel/cpu/mcheck/mce_amd.c +++ b/arch/x86/kernel/cpu/mcheck/mce_amd.c @@ -201,8 +201,8 @@ static void smca_configure(unsigned int bank, unsigned int cpu) wrmsr(smca_config, low, high); } - /* Collect bank_info using CPU 0 for now. */ - if (cpu) + /* Return early if this bank was already initialized. */ + if (smca_banks[bank].hwid) return; if (rdmsr_safe_on_cpu(cpu, MSR_AMD64_SMCA_MCx_IPID(bank), &low, &high)) { @@ -216,11 +216,6 @@ static void smca_configure(unsigned int bank, unsigned int cpu) for (i = 0; i < ARRAY_SIZE(smca_hwid_mcatypes); i++) { s_hwid = &smca_hwid_mcatypes[i]; if (hwid_mcatype == s_hwid->hwid_mcatype) { - - WARN(smca_banks[bank].hwid, - "Bank %s already initialized!\n", - smca_get_name(s_hwid->bank_type)); - smca_banks[bank].hwid = s_hwid; smca_banks[bank].id = low; smca_banks[bank].sysfs_id = s_hwid->count++; ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [tip:ras/core] x86/mce/AMD: Allow any CPU to initialize the smca_banks array @ 2017-07-25 13:55 ` tip-bot for Borislav Petkov 0 siblings, 0 replies; 12+ messages in thread From: tip-bot for Yazen Ghannam @ 2017-07-25 13:55 UTC (permalink / raw) To: linux-tip-commits Cc: bp, torvalds, peterz, tony.luck, tglx, jack, mingo, yazen.ghannam, hpa, linux-edac, linux-kernel Commit-ID: 9662d43f523dfc0dc242ec29c2921c43898d6ae5 Gitweb: http://git.kernel.org/tip/9662d43f523dfc0dc242ec29c2921c43898d6ae5 Author: Yazen Ghannam <yazen.ghannam@amd.com> AuthorDate: Mon, 24 Jul 2017 12:12:28 +0200 Committer: Ingo Molnar <mingo@kernel.org> CommitDate: Tue, 25 Jul 2017 15:50:53 +0200 x86/mce/AMD: Allow any CPU to initialize the smca_banks array Current SMCA implementations have the same banks on each CPU with the non-core banks only visible to a "master thread" on each die. Practically, this means the smca_banks array, which describes the banks, only needs to be populated once by a single master thread. CPU 0 seemed like a good candidate to do the populating. However, it's possible that CPU 0 is not enabled in which case the smca_banks array won't be populated. Rather than try to figure out another master thread to do the populating, we should just allow any CPU to populate the array. Drop the CPU 0 check and return early if the bank was already initialized. Also, drop the WARNing about an already initialized bank, since this will be a common, expected occurrence. The smca_banks array is only populated at boot time and CPUs are brought online sequentially. So there's no need for locking around the array. If the first CPU up is a master thread, then it will populate the array with all banks, core and non-core. Every CPU afterwards will return early. If the first CPU up is not a master thread, then it will populate the array with all core banks. The first CPU afterwards that is a master thread will skip populating the core banks and continue populating the non-core banks. Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Jack Miller <jack@codezen.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tony Luck <tony.luck@intel.com> Cc: linux-edac <linux-edac@vger.kernel.org> Link: http://lkml.kernel.org/r/20170724101228.17326-4-bp@alien8.de Signed-off-by: Ingo Molnar <mingo@kernel.org> --- arch/x86/kernel/cpu/mcheck/mce_amd.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/arch/x86/kernel/cpu/mcheck/mce_amd.c b/arch/x86/kernel/cpu/mcheck/mce_amd.c index 9e314bc..5ce1a56 100644 --- a/arch/x86/kernel/cpu/mcheck/mce_amd.c +++ b/arch/x86/kernel/cpu/mcheck/mce_amd.c @@ -201,8 +201,8 @@ static void smca_configure(unsigned int bank, unsigned int cpu) wrmsr(smca_config, low, high); } - /* Collect bank_info using CPU 0 for now. */ - if (cpu) + /* Return early if this bank was already initialized. */ + if (smca_banks[bank].hwid) return; if (rdmsr_safe_on_cpu(cpu, MSR_AMD64_SMCA_MCx_IPID(bank), &low, &high)) { @@ -216,11 +216,6 @@ static void smca_configure(unsigned int bank, unsigned int cpu) for (i = 0; i < ARRAY_SIZE(smca_hwid_mcatypes); i++) { s_hwid = &smca_hwid_mcatypes[i]; if (hwid_mcatype == s_hwid->hwid_mcatype) { - - WARN(smca_banks[bank].hwid, - "Bank %s already initialized!\n", - smca_get_name(s_hwid->bank_type)); - smca_banks[bank].hwid = s_hwid; smca_banks[bank].id = low; smca_banks[bank].sysfs_id = s_hwid->count++; ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [tip:ras/core] x86/mce/AMD: Allow any CPU to initialize the smca_banks array @ 2017-07-25 13:55 ` tip-bot for Borislav Petkov 0 siblings, 0 replies; 12+ messages in thread From: tip-bot for Borislav Petkov @ 2017-07-25 13:55 UTC (permalink / raw) To: linux-tip-commits Cc: bp, torvalds, peterz, tony.luck, tglx, jack, mingo, yazen.ghannam, hpa, linux-edac, linux-kernel Commit-ID: 9662d43f523dfc0dc242ec29c2921c43898d6ae5 Gitweb: http://git.kernel.org/tip/9662d43f523dfc0dc242ec29c2921c43898d6ae5 Author: Yazen Ghannam <yazen.ghannam@amd.com> AuthorDate: Mon, 24 Jul 2017 12:12:28 +0200 Committer: Ingo Molnar <mingo@kernel.org> CommitDate: Tue, 25 Jul 2017 15:50:53 +0200 x86/mce/AMD: Allow any CPU to initialize the smca_banks array Current SMCA implementations have the same banks on each CPU with the non-core banks only visible to a "master thread" on each die. Practically, this means the smca_banks array, which describes the banks, only needs to be populated once by a single master thread. CPU 0 seemed like a good candidate to do the populating. However, it's possible that CPU 0 is not enabled in which case the smca_banks array won't be populated. Rather than try to figure out another master thread to do the populating, we should just allow any CPU to populate the array. Drop the CPU 0 check and return early if the bank was already initialized. Also, drop the WARNing about an already initialized bank, since this will be a common, expected occurrence. The smca_banks array is only populated at boot time and CPUs are brought online sequentially. So there's no need for locking around the array. If the first CPU up is a master thread, then it will populate the array with all banks, core and non-core. Every CPU afterwards will return early. If the first CPU up is not a master thread, then it will populate the array with all core banks. The first CPU afterwards that is a master thread will skip populating the core banks and continue populating the non-core banks. Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Jack Miller <jack@codezen.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tony Luck <tony.luck@intel.com> Cc: linux-edac <linux-edac@vger.kernel.org> Link: http://lkml.kernel.org/r/20170724101228.17326-4-bp@alien8.de Signed-off-by: Ingo Molnar <mingo@kernel.org> --- arch/x86/kernel/cpu/mcheck/mce_amd.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-edac" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/arch/x86/kernel/cpu/mcheck/mce_amd.c b/arch/x86/kernel/cpu/mcheck/mce_amd.c index 9e314bc..5ce1a56 100644 --- a/arch/x86/kernel/cpu/mcheck/mce_amd.c +++ b/arch/x86/kernel/cpu/mcheck/mce_amd.c @@ -201,8 +201,8 @@ static void smca_configure(unsigned int bank, unsigned int cpu) wrmsr(smca_config, low, high); } - /* Collect bank_info using CPU 0 for now. */ - if (cpu) + /* Return early if this bank was already initialized. */ + if (smca_banks[bank].hwid) return; if (rdmsr_safe_on_cpu(cpu, MSR_AMD64_SMCA_MCx_IPID(bank), &low, &high)) { @@ -216,11 +216,6 @@ static void smca_configure(unsigned int bank, unsigned int cpu) for (i = 0; i < ARRAY_SIZE(smca_hwid_mcatypes); i++) { s_hwid = &smca_hwid_mcatypes[i]; if (hwid_mcatype == s_hwid->hwid_mcatype) { - - WARN(smca_banks[bank].hwid, - "Bank %s already initialized!\n", - smca_get_name(s_hwid->bank_type)); - smca_banks[bank].hwid = s_hwid; smca_banks[bank].id = low; smca_banks[bank].sysfs_id = s_hwid->count++; ^ permalink raw reply related [flat|nested] 12+ messages in thread
end of thread, other threads:[~2017-08-05 6:16 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-07-24 10:12 [PATCH 0/3] x86 stuff for 4.14 Borislav Petkov 2017-07-24 10:12 ` [PATCH 1/3] x86/microcode/AMD: Free unneeded patch before exit from update_cache() Borislav Petkov 2017-07-25 13:50 ` [tip:x86/microcode] " tip-bot for Shu Wang 2017-07-24 10:12 ` [PATCH 2/3] x86/microcode: Document the three loading methods Borislav Petkov 2017-07-25 13:51 ` [tip:x86/microcode] " tip-bot for Borislav Petkov 2017-08-04 11:24 ` Paul Menzel 2017-08-05 6:15 ` Borislav Petkov 2017-07-24 10:12 ` [PATCH 3/3] x86/mce/AMD: Allow any CPU to initialize smca_banks array Borislav Petkov 2017-07-25 13:51 ` [tip:ras/core] x86/mce/AMD: Allow any CPU to initialize the " tip-bot for Yazen Ghannam 2017-07-25 13:51 ` tip-bot for Borislav Petkov 2017-07-25 13:55 ` tip-bot for Yazen Ghannam 2017-07-25 13:55 ` tip-bot for Borislav Petkov
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.