From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from userp2120.oracle.com ([156.151.31.85]) by Galois.linutronix.de with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fBN1t-0004Qi-K3 for speck@linutronix.de; Wed, 25 Apr 2018 18:12:26 +0200 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w3PGBT3x124964 for ; Wed, 25 Apr 2018 16:12:19 GMT Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2120.oracle.com with ESMTP id 2hfwy9qft8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 25 Apr 2018 16:12:18 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w3PGCHBw008852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 25 Apr 2018 16:12:17 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w3PGCHHi008921 for ; Wed, 25 Apr 2018 16:12:17 GMT Date: Wed, 25 Apr 2018 12:12:14 -0400 From: Konrad Rzeszutek Wilk Subject: [MODERATED] Re: [PATCH v4 06/10] [PATCH v4 6/9] Linux Patch #6 Message-ID: <20180425161214.GD27641@localhost.localdomain> References: <20180424031751.311879235@dhcp-10-159-147-220.vpn.oracle.com> <20180424132156.GF15235@pd.tnic> <20180424154652.GC24865@dhcp-10-159-147-220.vpn.oracle.com> <20180424163656.GI15235@pd.tnic> MIME-Version: 1.0 In-Reply-To: <20180424163656.GI15235@pd.tnic> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Tue, Apr 24, 2018 at 06:36:56PM +0200, speck for Borislav Petkov wrote: > On Tue, Apr 24, 2018 at 11:46:53AM -0400, speck for Konrad Rzeszutek Wilk wrote: > > You OK with it moving the nicely aligned ( 7*32.. and so on?): It will > > look like this: > > > > 215 #define X86_FEATURE_USE_IBPB ( 7*32+21) /* "" Indirect Branch Prediction Barrier enabled */ > > 216 #define X86_FEATURE_USE_IBRS_FW ( 7*32+22) /* "" Use IBRS during runtime firmware calls */ > > 217 #define X86_FEATURE_SPEC_STORE_BYPASS_DISABLE ( 7*32+23) /* "" Disable Speculative Store Bypass. */ > > 218 > > Yeah, Ingo will have to realign them again :-) > > > Right, which on Intel can also be guarded by X86_FEATURE_RDS and on AMD > > it was implicit by the families (15h->17h). (The v4, patch #7 has that > > logic). The v2 (or v1.7) of the posting had the logic you just described but > > with different names. > > So I'd like for us to use a single one - either X86_FEATURE_RDS or > X86_FEATURE_SPEC_STORE_BYPASS_DISABLE globally. No need to cause > unnecessary confusion with two things meaning roughly the same thing. This is the part that won't work (sorry about not spotting this earlier). That is X86_FEATURE_RDS gets sets on Intel when we slurp up CPUID_7_EDX: 789 /* Additional Intel-defined flags: level 0x00000007 */ 790 if (c->cpuid_level >= 0x00000007) { 791 cpuid_count(0x00000007, 0, &eax, &ebx, &ecx, &edx); 792 c->x86_capability[CPUID_7_0_EBX] = ebx; 793 c->x86_capability[CPUID_7_ECX] = ecx; 794 c->x86_capability[CPUID_7_EDX] = edx; 795 } >From there on Intel we have the 'rds' flag already set. Which means that the logic in Intel code, as you suggested: 688 if (cpu_has(c, X86_FEATURE_RDS)) 689 x86_set_spec_ctrl(SPEC_CTRL_RDS); will always do its thing. Unless in bugs.c we end up clearing the RDS flag: 459 if (mode == SPEC_STORE_BYPASS_NONE) 460 setup_clear_cpu_cap(X86_FEATURE_RDS); 461 else { 462 if (boot_cpu_has(X86_FEATURE_RDS)) 463 x86_spec_ctrl_base |= SPEC_CTRL_RDS; 464 465 } ?