From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754500AbcA3K2P (ORCPT ); Sat, 30 Jan 2016 05:28:15 -0500 Received: from mail.skyhub.de ([78.46.96.112]:53912 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752996AbcA3K2N (ORCPT ); Sat, 30 Jan 2016 05:28:13 -0500 Date: Sat, 30 Jan 2016 11:28:03 +0100 From: Borislav Petkov To: Tony Luck Cc: Ingo Molnar , Dan Williams , Andy Lutomirski , linux-nvdimm , "linux-kernel@vger.kernel.org" , Andrew Morton , Robert , "linux-mm@kvack.org" , X86 ML Subject: Re: [PATCH v8 3/3] x86, mce: Add __mcsafe_copy() Message-ID: <20160130102803.GB15296@pd.tnic> References: <20160110112635.GC22896@pd.tnic> <20160111104425.GA29448@gmail.com> <20160114043956.GA8496@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 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 On Fri, Jan 29, 2016 at 04:35:35PM -0800, Tony Luck wrote: > On Wed, Jan 13, 2016 at 8:39 PM, Borislav Petkov wrote: > > On Wed, Jan 13, 2016 at 03:22:58PM -0800, Tony Luck wrote: > >> Are there some examples of synthetic CPUID bits? > > > > X86_FEATURE_ALWAYS is one. The others got renamed into X86_BUG_* ones, > > the remaining mechanism is the same, though. > > So something like this [gmail will line wrap, but should still be legible] > > Then Dan will be able to use: > > if (cpu_has(c, X86_FEATURE_MCRECOVERY)) > > to decide whether to use the (slightly slower, but recovery capable) > __mcsafe_copy() > or just pick the fastest memcpy() instead. The most optimal way of alternatively calling two functions would be something like this, IMO: alternative_call(memcpy, __mcsafe_copy, X86_FEATURE_MCRECOVERY, ASM_OUTPUT2("=a" (mcsafe_ret.trapnr), "=d" (mcsafe_ret.remain)), "D" (dst), "S" (src), "d" (len)); I hope I've not messed up the calling convention but you want the inputs in %rdi, %rsi, %rdx and the outputs in %rax, %rdx, respectively. Just check the asm gcc generates and do not trust me :) The other thing you probably would need to do is create our own __memcpy() which returns struct mcsafe_ret so that the signatures of both functions match. Yeah, it is a bit of jumping through hoops but this way we do a CALL directly in asm, without any JMPs or NOPs padding the other alternatives methods add. But if you don't care about a small JMP and that is not a hot path, you could do the simpler: if (static_cpu_has(X86_FEATURE_MCRECOVERY)) return __mcsafe_copy(...); return memcpy(); which adds a JMP or a 5-byte NOP depending on the X86_FEATURE_MCRECOVERY setting. > diff --git a/arch/x86/include/asm/cpufeature.h > b/arch/x86/include/asm/cpufeature.h > index 7ad8c9464297..621e05103633 100644 > --- a/arch/x86/include/asm/cpufeature.h > +++ b/arch/x86/include/asm/cpufeature.h > @@ -106,6 +106,7 @@ > #define X86_FEATURE_APERFMPERF ( 3*32+28) /* APERFMPERF */ > #define X86_FEATURE_EAGER_FPU ( 3*32+29) /* "eagerfpu" Non lazy FPU restore */ > #define X86_FEATURE_NONSTOP_TSC_S3 ( 3*32+30) /* TSC doesn't stop in > S3 state */ > +#define X86_FEATURE_MCRECOVERY ( 3*32+31) /* cpu has recoverable Why not write it out? X86_FEATURE_MCE_RECOVERY > machine checks */ > > /* Intel-defined CPU features, CPUID level 0x00000001 (ecx), word 4 */ > #define X86_FEATURE_XMM3 ( 4*32+ 0) /* "pni" SSE-3 */ -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.