[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3908561D78D1C84285E8C5FCA982C28F7B388473@ORSMSX110.amr.corp.intel.com>
Date: Thu, 1 Mar 2018 16:38:24 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: Borislav Petkov <bp@...e.de>, Yazen Ghannam <Yazen.Ghannam@....com>
CC: "linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"ard.biesheuvel@...aro.org" <ard.biesheuvel@...aro.org>,
"x86@...nel.org" <x86@...nel.org>
Subject: RE: [PATCH v2 0/8] Decode IA32/X64 CPER
> One much more important thing I forgot about yesterday: how is
> this thing playing into our RAS reporting, x86 decoding chain, etc
> infrastructure?
>
> Is CPER bypassing it completely and the firmware is doing everything
> now? I sure hope not.
Intel gives OEMs lots of options to catch and tweak the error path in
BIOS SMM code. So it is possible that some systems may go into
BIOS which would do platform level analysis and create a CPER to
feed to the OS. Hopefully anyone doing that would clear the machine
check bank and suppress CMCI to avoid double reporting the same
error.
> If not, it needs to tie into our infrastructure and the errors need
> to go into the decoding chain where different things look at them and
> filter them.
Good point.
> Tony, what are your plans here?
Nothing solid yet.
> Perhaps we can finally get MCE decoding on Intel too :-)
It's on a mental list ... I should probably add it to our internal
trackers so that we actually do it sooner rather than in some
distant future.
-Tony
Powered by blists - more mailing lists