From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41]) by kanga.kvack.org (Postfix) with ESMTP id 15BE6828F3 for ; Sat, 9 Jan 2016 20:40:07 -0500 (EST) Received: by mail-wm0-f41.google.com with SMTP id f206so221346872wmf.0 for ; Sat, 09 Jan 2016 17:40:07 -0800 (PST) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com. [2a00:1450:400c:c09::244]) by mx.google.com with ESMTPS id x11si10854382wmx.51.2016.01.09.17.40.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Jan 2016 17:40:05 -0800 (PST) Received: by mail-wm0-x244.google.com with SMTP id f206so21213968wmf.2 for ; Sat, 09 Jan 2016 17:40:05 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <19f6403f2b04d3448ed2ac958e656645d8b6e70c.1452297867.git.tony.luck@intel.com> Date: Sat, 9 Jan 2016 17:40:05 -0800 Message-ID: Subject: Re: [PATCH v8 3/3] x86, mce: Add __mcsafe_copy() From: Tony Luck Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Dan Williams Cc: Andy Lutomirski , linux-nvdimm , Borislav Petkov , "linux-kernel@vger.kernel.org" , Andrew Morton , Robert , Ingo Molnar , "linux-mm@kvack.org" , X86 ML On Sat, Jan 9, 2016 at 4:23 PM, Dan Williams wrote: > On Sat, Jan 9, 2016 at 2:33 PM, Andy Lutomirski wrote: >> Shouldn't that logic live in the mcsafe_copy routine itself rather >> than being delegated to callers? >> > > Yes, please. Yes - we should have some of that fancy self-patching code that redirects to the optimal routine for the cpu model we are running on. 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. You might think that MCG_CAP{24} which is described as "software error recovery" (or some such) would be a good clue, but you'd be wrong. The bit got a little overloaded and there are cpus that set it, but won't recover. Only Intel(R) Xeon(R) branded cpus can recover, but not all. The story so far: Nehalem, Westmere: E7 models support SRAO recovery (patrol scrub, cache eviction). Not relevant for this e-mail thread. Sandy Bridge: Some "advanced RAS" skus will recover from poison reads (these have E5 model names, there was no E7 in this generation) Ivy Bridge: Xeon E5-* models do not recover. E7-* models do recover. Note E5 and E7 have the same CPUID model number. Haswell: Same as Ivy Bridge Broadwell/Sky Lake: Xeon not released yet ... can't talk about them. Linux code recently got some recovery bits for AMD cpus ... I don't know what the story is on which models support this, -Tony -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org