[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160110112635.GC22896@pd.tnic>
Date: Sun, 10 Jan 2016 12:26:35 +0100
From: Borislav Petkov <bp@...en8.de>
To: Tony Luck <tony.luck@...il.com>
Cc: Dan Williams <dan.j.williams@...el.com>,
Andy Lutomirski <luto@...capital.net>,
linux-nvdimm <linux-nvdimm@...1.01.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Robert <elliott@....com>, Ingo Molnar <mingo@...nel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>, X86 ML <x86@...nel.org>
Subject: Re: [PATCH v8 3/3] x86, mce: Add __mcsafe_copy()
On Sat, Jan 09, 2016 at 05:40:05PM -0800, Tony Luck wrote:
> BUT ... it's all going to be very messy. We don't have any CPUID
> capability bits to say whether we support recovery, or which instructions
> are good/bad choices for recovery.
We can always define synthetic ones and set them after having checked
MCA capability bits, f/m/s, etc., maybe even based on the list you're
supplying...
> Linux code recently got some recovery bits for AMD cpus ... I don't
> know what the story is on which models support this,
You mean this?
/*
* overflow_recov is supported for F15h Models 00h-0fh
* even though we don't have a CPUID bit for it.
*/
if (c->x86 == 0x15 && c->x86_model <= 0xf)
mce_flags.overflow_recov = 1;
If so, that's just an improvement which makes MCi_STATUS[Overflow] MCEs
non-fatal.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
Powered by blists - more mailing lists