From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754544AbcH0H2r (ORCPT ); Sat, 27 Aug 2016 03:28:47 -0400 Received: from mail-wm0-f50.google.com ([74.125.82.50]:38236 "EHLO mail-wm0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751152AbcH0H2p (ORCPT ); Sat, 27 Aug 2016 03:28:45 -0400 Date: Sat, 27 Aug 2016 09:28:34 +0200 From: Ingo Molnar To: Tony Luck Cc: Boris Petkov , Dan Williams , "H. Peter Anvin" , Peter Zijlstra , Thomas Gleixner , Linus Torvalds , linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/4] Better memcpy_mcsafe() Message-ID: <20160827072833.GA10883@gmail.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Tony Luck wrote: > The original version of this used a check of the x86_model_id string > for the magic "Intel(R) Xeon(R) CPU E7-" to determine whether we are > running on a cpu that supports machine check recovery. > > Boris tried to talk me out of that, but at the time I didn't think > there was a viable alternate option, and somehow he fell for that line. > > It turns out there is a better way, that isn't as painful as I thought > it might be. It does help guarantee future employment, as I'll > have to add a new quirk for each CPU generation. But the check for "E7" > would have eventually failed and required a patch too. > > The downside of a quirk is that it runs after the X86_FEATURE patching > code. So instead of "static_cpu_has()" we use "static_branch_unlikely(&mcsafe_key)" So why not move it to the early PCI quirk code in arch/x86/ and get rid of this quirk within a quirk? Thanks, Ingo