Currently, the microcode field (Microcode Revision) of struct mce is not
exported to userspace through the mce_record tracepoint.
Knowing the microcode version on which the MCE was received is critical
information for debugging. If the version is not recorded, later attempts
to acquire the
Currently, the microcode field (Microcode Revision) of struct mce is not
exported to userspace through the mce_record tracepoint.
Knowing the microcode version on which the MCE was received is critical
information for debugging. If the version is not recorded, later attempts
to acquire the
On Thu, Mar 28, 2024 at 01:17:43AM -0500, Naik, Avadhut wrote:
> SOCKET -> Socket
> PROCESSOR -> Processor
> MICROCODE -> Microcode
SOCKET -> socket
PROCESSOR -> processor
MICROCODE -> microcode
And yeah, the acronyms need to obviously stay in all caps.
Thx.
-
6Lx>, TSC: %llx, PPIN:
>>> %llx, PROCESSOR: %u:%x, TIME: %llu, SOCKET: %u, APIC: %x, MICROCODE
>>> REVISION: %x",
>>
>> Nit: s/MICROCODE REVISION/MICROCODE/g
>>
>> You could probably get rid of the word REVISION in the interest of
>> brevity
SSOR: %u:%x, TIME: %llu, SOCKET: %u, APIC: %x",
>> +TP_printk("CPU: %d, MCGc/s: %llx/%llx, MC%d: %016Lx, IPID: %016Lx,
>> ADDR/MISC/SYND: %016Lx/%016Lx/%016Lx, RIP: %02x:<%016Lx>, TSC: %llx, PPIN:
>> %llx, PROCESSOR: %u:%x, TIME: %llu, SOCKET: %u, APIC: %x, MI
>
> You *definitely* want to do that - good catch.
>
> And TBH, all the screaming words aren't helping either... :)
>
:) I thought the same as well. But, I felt inconsistently screaming
words might be worse. Maybe just update all the words that are not
acronyms (such as Processor, Time, Socke
; > %llx, PROCESSOR: %u:%x, TIME: %llu, SOCKET: %u, APIC: %x",
> > + TP_printk("CPU: %d, MCGc/s: %llx/%llx, MC%d: %016Lx, IPID: %016Lx,
> > ADDR/MISC/SYND: %016Lx/%016Lx/%016Lx, RIP: %02x:<%016Lx>, TSC: %llx, PPIN:
> > %llx, PROCESSOR: %u:%x, TIME: %llu, SOCK
rintk("CPU: %d, MCGc/s: %llx/%llx, MC%d: %016Lx, IPID: %016Lx,
> ADDR/MISC/SYND: %016Lx/%016Lx/%016Lx, RIP: %02x:<%016Lx>, TSC: %llx, PPIN:
> %llx, PROCESSOR: %u:%x, TIME: %llu, SOCKET: %u, APIC: %x, MICROCODE REVISION:
> %x",
Nit: s/MICROCODE REVISION/MICROCODE/g
Y
> Export microcode version through the tracepoint to prevent ambiguity over
> the active version on the system when the MCE was received.
>
> Signed-off-by: Avadhut Naik
> Reviewed-by: Sohil Mehta
> Reviewed-by: Steven Rostedt (Google)
Reviewed-by: Tony Luck
Currently, the microcode field (Microcode Revision) of struct mce is not
exported to userspace through the mce_record tracepoint.
Knowing the microcode version on which the MCE was received is critical
information for debugging. If the version is not recorded, later attempts
to acquire the
Currently, the microcode field (Microcode Revision) of struct mce is not
exported to userspace through the mce_record tracepoint.
Export it through the tracepoint as it may provide useful information for
debug and analysis.
Signed-off-by: Avadhut Naik
Reviewed-by: Sohil Mehta
---
include
On 1/25/2024 3:03 PM, Sohil Mehta wrote:
> On 1/25/2024 10:48 AM, Avadhut Naik wrote:
>> Currently, the microcode field (Microcode Revision) of struct mce is not
>> exported to userspace through the mce_record tracepoint.
>>
>> Export it through the tracepoi
On 1/25/2024 10:48 AM, Avadhut Naik wrote:
> Currently, the microcode field (Microcode Revision) of struct mce is not
> exported to userspace through the mce_record tracepoint.
>
> Export it through the tracepoint as it may provide useful information for
> debug and analysis.
>
Currently, the microcode field (Microcode Revision) of struct mce is not
exported to userspace through the mce_record tracepoint.
Export it through the tracepoint as it may provide useful information for
debug and analysis.
Signed-off-by: Avadhut Naik
---
include/trace/events/mce.h | 7
On Mon, 2021-04-19 at 11:54 +0200, Gonsolo wrote:
> > Do you use MFP?
>
> I don't think so. I'm running unmodified kernels from Ubuntu PPA and
> don't meddle with WIFI configs.
> How can I find out?
>
> > Could be related to
> > https://patchwork.kernel.org/project/linux-wireless/patch/2021041613
> Do you use MFP?
I don't think so. I'm running unmodified kernels from Ubuntu PPA and
don't meddle with WIFI configs.
How can I find out?
> Could be related to
> https://patchwork.kernel.org/project/linux-wireless/patch/20210416134702.ef8486a64293.If0a9025b39c71bb91b11dd6ac45547aba682df34@change
On Mon, 2021-04-19 at 11:08 +0200, Gon Solo wrote:
>
> [Apr19 10:50] iwlwifi :02:00.0: Queue 10 is active on fifo 1 and stuck
> for 1 ms. SW [40, 93] HW [40, 93] FH TRB=0x0c010a037
> [ +0,001244] iwlwifi 0000:02:00.0: Microcode SW error detected. Restarting
> 0x200
Hi all!
My internet was very slow and I saw the following in dmesg:
[Apr19 10:50] iwlwifi :02:00.0: Queue 10 is active on fifo 1 and stuck for
1 ms. SW [40, 93] HW [40, 93] FH TRB=0x0c010a037
[ +0,001244] iwlwifi :02:00.0: Microcode SW error detected. Restarting
0x200.
The
From: Dmitry Baryshkov
[ Upstream commit 6ddbfa1f5adbd5dea14ff66778ca58257f09f17d ]
I suppose the microcode version check for a650 is incorrect. It checks
for the version 1.95, while the firmware released have major version of 0:
0.91 (vulnerable), 0.99 (fixing the issue).
Lower version
From: Jordan Crouse
[ Upstream commit 8490f02a3ca45fd1bbcadc243b4db9b69d0e3450 ]
Most a6xx targets have security issues that were fixed with new versions
of the microcode(s). Make sure that we are booting with a safe version of
the microcode for the target and print a message and error if not
Hello,
On 10/02/2021 03:52, Jordan Crouse wrote:
Most a6xx targets have security issues that were fixed with new versions
of the microcode(s). Make sure that we are booting with a safe version of
the microcode for the target and print a message and error if not.
v2: Add more informative error
From: Jordan Crouse
[ Upstream commit 8490f02a3ca45fd1bbcadc243b4db9b69d0e3450 ]
Most a6xx targets have security issues that were fixed with new versions
of the microcode(s). Make sure that we are booting with a safe version of
the microcode for the target and print a message and error if not
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
x86/microcode
branch HEAD: 7189b3c11903667808029ec9766a6e96de5012a5 x86/microcode: Check for
offline CPUs before requesting new microcode
elapsed time: 722m
configs tested: 76
configs skipped: 59
The following configs
The following commit has been merged into the x86/microcode branch of tip:
Commit-ID: 7189b3c11903667808029ec9766a6e96de5012a5
Gitweb:
https://git.kernel.org/tip/7189b3c11903667808029ec9766a6e96de5012a5
Author:Otavio Pontes
AuthorDate:Fri, 19 Mar 2021 09:55:15 -07:00
On Sat, Mar 20, 2021 at 03:55:46PM +0100, Borislav Petkov wrote:
[snip]
> > microcode : 0x30
> > microcode : 0xde
> > microcode : 0x30
> > microcode : 0xde
>
> Yeah, I'm looking at that check_online_cpus() thing and wondering why we
> even need that:
>
&
-ucode/06-8e-09 /lib/firmware/intel-ucode/
> $ echo 1 > /sys/devices/system/cpu/microcode/reload
> bash: echo: write error: Invalid argument
>
> Turn the core back on
> $ echo 1 > /sys/devices/system/cpu/cpu3/online
> $ echo 1 > /sys/devices/system/cpu/cpu1/online
> $ cat /
Sorry, I forgot to copy LKML
From: Pontes, Otavio
Sent: Friday, March 19, 2021 9:55 AM
To: x...@kernel.org
Cc: Borislav Petkov; Thomas Gleixner; Pontes, Otavio; Raj, Ashok; Luck, Tony
Subject: [PATCH 1/1] x86/microcode: Check for offline CPUs before
The pull request you sent on Mon, 15 Feb 2021 12:45:04 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> tags/x86_microcode_for_v5.12
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d00c4ed02e90c1a4290acdd4f9bc4d056a573859
Thank you!
--
Deet-doot-
Hi Linus,
please pull a single x86/microcode cleanup for v5.12.
Thx.
---
The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e:
Linux 5.11-rc1 (2020-12-27 15:30:22 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tip
On 2/11/2021 9:32 PM, Jordan Crouse wrote:
On Thu, Feb 11, 2021 at 06:50:28PM +0530, Akhil P Oommen wrote:
On 2/10/2021 6:22 AM, Jordan Crouse wrote:
Most a6xx targets have security issues that were fixed with new versions
of the microcode(s). Make sure that we are booting with a safe version
On Thu, Feb 11, 2021 at 06:50:28PM +0530, Akhil P Oommen wrote:
> On 2/10/2021 6:22 AM, Jordan Crouse wrote:
> >Most a6xx targets have security issues that were fixed with new versions
> >of the microcode(s). Make sure that we are booting with a safe version of
> >the microco
On 2/10/2021 6:22 AM, Jordan Crouse wrote:
Most a6xx targets have security issues that were fixed with new versions
of the microcode(s). Make sure that we are booting with a safe version of
the microcode for the target and print a message and error if not.
v2: Add more informative error
Most a6xx targets have security issues that were fixed with new versions
of the microcode(s). Make sure that we are booting with a safe version of
the microcode for the target and print a message and error if not.
v2: Add more informative error messages and fix typos
Signed-off-by: Jordan Crouse
Most a6xx targets have security issues that were fixed with new versions
of the microcode(s). Make sure that we are booting with a safe version of
the microcode for the target and print a message and error if not.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 67
8, bank)
> __field(u8, cpuvendor )
> + __field( u64,ppin)
> + __field(u32,microcode )
> ),
# trace-cmd list -e mce_record -F
system: mce
name: mce_re
eld(u64,ppin)
+ __field(u32, microcode )
),
TP_fast_assign(
@@ -53,9 +55,11 @@ TRACE_EVENT(mce_record,
__entry->cs = m->cs;
__entry->bank = m->ba
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
x86/microcode
branch HEAD: c769dcd423785703f17ca0a99925a7f9d84b3cbc x86/microcode: Make
microcode_init() static
elapsed time: 724m
configs tested: 64
configs skipped: 64
The following configs have been built
The following commit has been merged into the x86/microcode branch of tip:
Commit-ID: c769dcd423785703f17ca0a99925a7f9d84b3cbc
Gitweb:
https://git.kernel.org/tip/c769dcd423785703f17ca0a99925a7f9d84b3cbc
Author:Borislav Petkov
AuthorDate:Wed, 30 Dec 2020 11:20:25 +01:00
From: Borislav Petkov
No functional changes.
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/microcode.h | 2 --
arch/x86/kernel/cpu/microcode/core.c | 2 +-
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/microcode.h b/arch/x86/include/asm
The pull request you sent on Mon, 14 Dec 2020 12:22:29 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> tags/x86_microcode_update_for_v5.11
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/85fe40cad2dae9e0439ea6f92fde9c5e9c58f09b
Thank you!
--
Dee
Hi Linus,
this one wins the award for most boring pull request ever. But that's a
good thing - this is how I like 'em and the microcode loader *should* be
boring. :-)
Pls pull,
thx.
---
The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec:
Linux 5.10-rc1 (202
On Thu, Nov 26, 2020, Borislav Petkov wrote:
> On Thu, Nov 26, 2020 at 12:18:12AM +, Sean Christopherson wrote:
> > The SEAM module needs to be loaded during early boot, it can't be
> > deferred to a module, at least not without a lot more blood, sweat,
> > and tears.
>
> Are you also planning
On Thu, Nov 26, 2020 at 12:18:12AM +, Sean Christopherson wrote:
> The SEAM module needs to be loaded during early boot, it can't be
> deferred to a module, at least not without a lot more blood, sweat,
> and tears.
Are you also planning to support builtin seam or only thru initrd loading?
In
On Wed, Nov 25, 2020, Borislav Petkov wrote:
> On Mon, Nov 16, 2020 at 10:25:48AM -0800, isaku.yamah...@intel.com wrote:
> > From: Zhang Chen
> >
> > Move get_builtin_firmware() to common.c so that it can be used to get
> > non-ucode firmware, e.g. Intel's S
On Mon, Nov 16, 2020 at 10:25:48AM -0800, isaku.yamah...@intel.com wrote:
> From: Zhang Chen
>
> Move get_builtin_firmware() to common.c so that it can be used to get
> non-ucode firmware, e.g. Intel's SEAM modules, even if MICROCODE=n.
What for?
This is used for microcode bu
From: Chen Yu
commit 1a371e67dc77125736cc56d3a0893f06b75855b6 upstream.
Currently, scan_microcode() leverages microcode_matches() to check
if the microcode matches the CPU by comparing the family and model.
However, the processor stepping and flags of the microcode signature
should also be
From: Chen Yu
commit 1a371e67dc77125736cc56d3a0893f06b75855b6 upstream.
Currently, scan_microcode() leverages microcode_matches() to check
if the microcode matches the CPU by comparing the family and model.
However, the processor stepping and flags of the microcode signature
should also be
From: Chen Yu
commit 1a371e67dc77125736cc56d3a0893f06b75855b6 upstream.
Currently, scan_microcode() leverages microcode_matches() to check
if the microcode matches the CPU by comparing the family and model.
However, the processor stepping and flags of the microcode signature
should also be
From: Chen Yu
commit 1a371e67dc77125736cc56d3a0893f06b75855b6 upstream.
Currently, scan_microcode() leverages microcode_matches() to check
if the microcode matches the CPU by comparing the family and model.
However, the processor stepping and flags of the microcode signature
should also be
From: Chen Yu
commit 1a371e67dc77125736cc56d3a0893f06b75855b6 upstream.
Currently, scan_microcode() leverages microcode_matches() to check
if the microcode matches the CPU by comparing the family and model.
However, the processor stepping and flags of the microcode signature
should also be
From: Chen Yu
commit 1a371e67dc77125736cc56d3a0893f06b75855b6 upstream.
Currently, scan_microcode() leverages microcode_matches() to check
if the microcode matches the CPU by comparing the family and model.
However, the processor stepping and flags of the microcode signature
should also be
: Borislav Petkov
CommitterDate: Tue, 17 Nov 2020 10:33:18 +01:00
x86/microcode/intel: Check patch signature before saving microcode for early
loading
Currently, scan_microcode() leverages microcode_matches() to check
if the microcode matches the CPU by comparing the family and model.
However
On Tue, Nov 17, 2020 at 10:18:37AM +0100, Borislav Petkov wrote:
> On Tue, Nov 17, 2020 at 10:25:18AM +0800, Chen Yu wrote:
> > If I understand correctly, the only place that invokes
> > save_mc_for_early() is in generic_load_microcode(). While in
> > generic_load_microcode()
On Tue, Nov 17, 2020 at 10:25:18AM +0800, Chen Yu wrote:
> If I understand correctly, the only place that invokes
> save_mc_for_early() is in generic_load_microcode(). While in
> generic_load_microcode() only microcode has a newer version will be
> saved by checking has_newer_microcode
ode() leverages microcode_matches() to check if the
> > microcode matches the CPU by comparing the family and model. However before
> > saving the microcode in scan_microcode(), the processor stepping and flag
> > of the microcode signature should also be considered in order to avoid
> > inc
On Mon, Nov 16, 2020 at 01:30:19PM -0800, Raj, Ashok wrote:
> Stable is still left below. with #v4.10+
>
> Do you want to keep this? Also do you want him to resend or you have that
> covered?
No Ashok, read the section
"For all other submissions, choose one of the following procedures"
here: Do
Fri, Nov 13, 2020 at 09:59:23AM +0800, Chen Yu wrote:
> > Currently scan_microcode() leverages microcode_matches() to check if the
> > microcode matches the CPU by comparing the family and model. However before
> > saving the microcode in scan_microcode(), the processor stepping an
From: Zhang Chen
Move get_builtin_firmware() to common.c so that it can be used to get
non-ucode firmware, e.g. Intel's SEAM modules, even if MICROCODE=n.
Require the consumers to select FW_LOADER, which is already true for
MICROCODE, instead of having dead code that returns false at ru
( drop stable@ from Cc because this is not how fixes get added to stable@ )
On Fri, Nov 13, 2020 at 09:59:23AM +0800, Chen Yu wrote:
> Currently scan_microcode() leverages microcode_matches() to check if the
> microcode matches the CPU by comparing the family and model. However before
&g
Currently scan_microcode() leverages microcode_matches() to check if the
microcode matches the CPU by comparing the family and model. However before
saving the microcode in scan_microcode(), the processor stepping and flag
of the microcode signature should also be considered in order to avoid
Tue, Nov 10, 2020 at 09:52:47PM +0800, Chen Yu wrote:
> > Currently scan_microcode() leverages microcode_matches() to check if the
> > microcode matches the CPU by comparing the family and model. However before
> > saving the microcode in scan_microcode(), the processor stepping a
Hi ChenYu
I think you can drop the RFC tag.
I suppose you can add Cc stable as well. Boris should return next week to
take a look.
On Tue, Nov 10, 2020 at 09:52:47PM +0800, Chen Yu wrote:
> Currently scan_microcode() leverages microcode_matches() to check if the
> microcode matches the
Currently scan_microcode() leverages microcode_matches() to check if the
microcode matches the CPU by comparing the family and model. However before
saving the microcode in scan_microcode(), the processor stepping and flag
of the microcode signature should also be considered in order to avoid
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
x86/microcode
branch HEAD: 880396c86a1f3663c22b74fef34353f05a1263ec x86/microcode/amd:
Remove unneeded break
elapsed time: 725m
configs tested: 173
configs skipped: 62
The following configs have been built successfully
The following commit has been merged into the x86/microcode branch of tip:
Commit-ID: 880396c86a1f3663c22b74fef34353f05a1263ec
Gitweb:
https://git.kernel.org/tip/880396c86a1f3663c22b74fef34353f05a1263ec
Author:Tom Rix
AuthorDate:Mon, 19 Oct 2020 13:06:29 -07:00
Committer
From: Tom Rix
A break is not needed if it is preceded by a return
Signed-off-by: Tom Rix
---
arch/x86/kernel/cpu/microcode/amd.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/microcode/amd.c
b/arch/x86/kernel/cpu/microcode/amd.c
index 3f6b137ef4e6..3d4a48336084
The pull request you sent on Mon, 3 Aug 2020 20:32:56 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> x86-microcode-2020-08-03
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/69094c20323c5efff462a2e02d0bb7b6608779ad
Thank you!
--
Deet-do
Linus,
Please pull the latest x86/microcode git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
x86-microcode-2020-08-03
# HEAD: c8a59a4d8e3c9e609fa915e39c3628c6dd08aeea x86/microcode: Do not
select FW_LOADER
A single commit that removes the microcode loader&#
Sean Christopherson writes:
> On Thu, Jul 02, 2020 at 06:18:20PM +0300, Mihai Carabas wrote:
>> This RFC patch set aims to provide the ability to re-evaluate all CPU
>> features and take proper bug mitigation in place after a microcode
>> late loading.
>>
>> Th
On Thu, Jul 02, 2020 at 06:18:20PM +0300, Mihai Carabas wrote:
> This RFC patch set aims to provide the ability to re-evaluate all CPU
> features and take proper bug mitigation in place after a microcode
> late loading.
>
> This was debated last year and this patch set impleme
While doing microcode late loading, need to probe again all the
CPU features after the microcode has been loaded. Before probing
the CPU features and bug, need to clear the current bug bits. The
new function, cpu_clear_bug_bits, will clear all the bug bits and
then set them.
The logic is as
This RFC patch set aims to provide the ability to re-evaluate all CPU
features and take proper bug mitigation in place after a microcode
late loading.
This was debated last year and this patch set implements a subset of
point #2 from Thomas Gleixner's idea:
https://lore.kernel.org/lkml/alpin
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
x86/microcode
branch HEAD: c8a59a4d8e3c9e609fa915e39c3628c6dd08aeea x86/microcode: Do not
select FW_LOADER
elapsed time: 486m
configs tested: 112
configs skipped: 79
The following configs have been built successfully
The following commit has been merged into the x86/microcode branch of tip:
Commit-ID: c8a59a4d8e3c9e609fa915e39c3628c6dd08aeea
Gitweb:
https://git.kernel.org/tip/c8a59a4d8e3c9e609fa915e39c3628c6dd08aeea
Author:Herbert Xu
AuthorDate:Wed, 10 Jun 2020 21:05:13 +10:00
unch of code for a trivial function.
>
> What I could do in addition is move that trivial function into a
> fw-specific header and have it defined unconditionally so that the
> microcode loader can use it without needing the fw loader.
Would just have to see this part. But sounds like a better place than
today.
> The testcases stuff then goes ontop.
Sure!
Luis
n to not be modular, and just
> built-in or disabled.
I don't mind doing the work but Herbert has a point - there's no need to
require a bunch of code for a trivial function.
What I could do in addition is move that trivial function into a
fw-specific header and have it defined unconditi
On Wed, Jun 10, 2020 at 10:16:09AM +0200, Borislav Petkov wrote:
>
> Also, I'm working on removing that homegrown get_builtin_firmware() and
> use the one in the fw loader:
>
> https://lkml.kernel.org/r/20200408094526.gc24...@zn.tnic
I would like to still encourage this, even with this patch in
On Wed, Jun 10, 2020 at 12:48:45PM +0200, Borislav Petkov wrote:
>
> Why isn't *this* in your commit message?
Sure, here it is.
---8<---
The x86 microcode support works just fine without FW_LOADER. In
fact these days most people load them early in boot so FW_LOADER
never gets in
On Wed, Jun 10, 2020 at 08:41:13PM +1000, Herbert Xu wrote:
> Adding two thousand lines of code to the kernel when you only need
> a few lines is ridiculous. Worse those two thousand lines increase
> the attack surface to the kernel because they're exposed to user-
> space.
Why isn't *this* in yo
On Wed, Jun 10, 2020 at 12:34:18PM +0200, Borislav Petkov wrote:
>
> Out Kconfig symbols space is a mess and I'd prefer not to add another
> one if there's no good reason for it.
Adding two thousand lines of code to the kernel when you only need
a few lines is ridiculous. Worse those two thousan
On Wed, Jun 10, 2020 at 08:28:51PM +1000, Herbert Xu wrote:
> Because MICROCODE is the only thing on my system that pulls it
> into the kernel.
That's a very interesting system you have.
> That shouldn't be a problem. That function can simply move under
> another (hidde
On Wed, Jun 10, 2020 at 10:16:09AM +0200, Borislav Petkov wrote:
> On Wed, Jun 10, 2020 at 02:29:11PM +1000, Herbert Xu wrote:
> > The x86 microcode support works just fine without FW_LOADER. In
> > fact these days most people load them early in boot so FW_LOADER
> > never
On Wed, Jun 10, 2020 at 02:29:11PM +1000, Herbert Xu wrote:
> The x86 microcode support works just fine without FW_LOADER. In
> fact these days most people load them early in boot so FW_LOADER
> never gets into the picture anyway.
What's the use case here?
$ git grep -E "sele
The x86 microcode support works just fine without FW_LOADER. In
fact these days most people load them early in boot so FW_LOADER
never gets into the picture anyway.
People who need the FW_LOADER capability can still enable it.
Signed-off-by: Herbert Xu
diff --git a/arch/x86/Kconfig b/arch/x86
The pull request you sent on Mon, 1 Jun 2020 11:31:13 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> tags/x86_microcode_for_5.8
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ef34ba6d36af9e6f5918f7f7e287be4b70a358b4
Thank you!
--
Deet-doot-dot
/x86_microcode_for_5.8
for you to fetch changes up to 9adbf3c609af92a57a73000a3cb8f4c2d307dfa3:
x86/microcode: Fix return value for microcode late loading (2020-04-22
19:55:50 +0200)
A single fix for late microcode loading to handle
04.2020 10:27, Mihai Carabas a scris:
> >This RFC patch set aims to provide a way to identify the modifications
> >brought in by the new microcode updated at runtime (aka microcode late
> >loading). This was debated last year and this patch set implements
> >point #1
La 27.04.2020 10:27, Mihai Carabas a scris:
This RFC patch set aims to provide a way to identify the modifications
brought in by the new microcode updated at runtime (aka microcode late
loading). This was debated last year and this patch set implements
point #1 from Thomas Gleixner's idea:
> Subject: Re: [PATCH RFC 1/3] x86: microcode: intel: read microcode metadata
> file
For the future, do:
git log
to figure out what commit title prefix to use for the tip tree.
On Mon, Apr 27, 2020 at 10:27:57AM +0300, Mihai Carabas wrote:
> Try to read the microcode metadata file
e express that.
IOW, I think it would be easier if each line describes exactly *one*
software-visible change brought by the microcode.
Also, what is the use case to say that you're adding a new MSR?
This would require to patch all the code that *potentially* might use
that MSR, to be able to h
On Mon, Oct 21, 2019 at 8:54 AM Allen, John wrote:
>
> * Update AMD cpu microcode for processor family 17h
>
> Key Name = AMD Microcode Signing Key (for signing microcode container
> files only)
> Key ID = F328AE73
> Key Fingerprint = FC7C 6C50 5DAF CC14 718
* Update AMD cpu microcode for processor family 17h
Key Name= AMD Microcode Signing Key (for signing microcode container
files only)
Key ID = F328AE73
Key Fingerprint = FC7C 6C50 5DAF CC14 7183 57CA E4BE 5339 F328 AE73
Signed-off-by: John Allen
---
WHENCE
The following commit has been merged into the x86/microcode branch of tip:
Commit-ID: 811ae8ba6dca6b91a3ceccf9d40b98818cc4f400
Gitweb:
https://git.kernel.org/tip/811ae8ba6dca6b91a3ceccf9d40b98818cc4f400
Author:Borislav Petkov
AuthorDate:Sat, 24 Aug 2019 10:01:53 +02:00
The following commit has been merged into the x86/microcode branch of tip:
Commit-ID: 93946a33b5693a6bbcf917a170198ff4afaa7a31
Gitweb:
https://git.kernel.org/tip/93946a33b5693a6bbcf917a170198ff4afaa7a31
Author:Ashok Raj
AuthorDate:Thu, 22 Aug 2019 23:43:47 +03:00
The following commit has been merged into the x86/microcode branch of tip:
Commit-ID: 2b730952066cd022d1f46e801f06ca6ca9878823
Gitweb:
https://git.kernel.org/tip/2b730952066cd022d1f46e801f06ca6ca9878823
Author:Borislav Petkov
AuthorDate:Sat, 28 Sep 2019 16:53:56 +02:00
From: Borislav Petkov
The dummy variable is the high part of the microcode revision MSR which
is defined as reserved. Mark it unused so that W=1 builds don't trigger
the above warning.
No functional changes.
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/cpu/microcode/amd.c | 4 ++
: CPU features
have changed after loading microcode, but might not take effect.").
Removing a CPU feature bit could be problematic. Other than HLE being
removed on Haswell (which the kernel shouldn't use anyway), have there
been any other cases?
I ask because we have successfully used
Hi Thomas,
On Tue, Sep 17, 2019 at 08:37:10AM +0200, Thomas Gleixner wrote:
> > microode updates should be of 3 types.
> >
> > - Only loadable from BIOS (Only via FIT tables)
> > - Suitable for early load (things that take cpuid bits for e.g.)
> > - Suitable for late-load. (Where no cpuid bits sh
On Tue, Sep 17, 2019 at 08:37:10AM +0200, Thomas Gleixner wrote:
> So what happens if the ucode update "fixes" one of the executed
> instructions on the fly? Is that guaranteed to be safe? There is nothing
> which says so.
You'd expect that when you load microcode on the c
de update affects any instruction which might be in use during the update
> > on a sibling. Right now it's all load and pray and the SDM is not really
> > helpful with that either.
> >
>
> Guilty as charged :-). In general we do not expect microcode updates to
> re
1 - 100 of 1633 matches
Mail list logo
