From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (193.142.43.55:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 24 Oct 2019 19:45:20 -0000 Received: from mx2.suse.de ([195.135.220.15] helo=mx1.suse.de) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iNj2s-0007kE-C6 for speck@linutronix.de; Thu, 24 Oct 2019 21:45:19 +0200 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id C7C12B239 for ; Thu, 24 Oct 2019 19:45:10 +0000 (UTC) Date: Thu, 24 Oct 2019 21:45:03 +0200 From: Borislav Petkov Subject: [MODERATED] Re: [PATCH 3/9] TAA 3 Message-ID: <20191024194503.GH14115@zn.tnic> References: <580e02757c3e639bff00fcea830aa46eba46a92f.1571905227.git.bp@suse.de> <6f1ab744-622c-179b-276b-5506b2fd9ae1@citrix.com> MIME-Version: 1.0 In-Reply-To: <6f1ab744-622c-179b-276b-5506b2fd9ae1@citrix.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: speck@linutronix.de List-ID: On Thu, Oct 24, 2019 at 06:39:35PM +0100, speck for Andrew Cooper wrote: > On 23/10/2019 10:01, speck for Pawan Gupta wrote: > > + if (tsx_ctrl_state =3D=3D TSX_CTRL_DISABLE) { > > + tsx_disable(); > > + > > + /* > > + * tsx_disable() will change the state of the > > + * RTM CPUID bit. Clear it here since it is now > > + * expected to be not set. > > + */ > > + setup_clear_cpu_cap(X86_FEATURE_RTM); >=20 > This same argument applies to HLE, and it would be weird for > pre-TSX_CTRL CPUs with tsx=3Doff to report HLE but not RTM in /proc/cpuid Right, the correct fix for that would be to run tsx_init() before we read CPUID leafs in get_cpu_cap() because then it'll load the proper bits already and we won't have to clear anything - the MSR write would've cleared both CPUID bits already. I just checked that it happens globally even: $ ./cpuid -r | grep -E "^\s+0x00000007" | awk '{ print $6 }' | uniq edx=3D0xbc000400 Bits 4 (HLE) and 11 (RTM) are cleared on all CPUs. I'll try this tomorrow to check whether it would even work that early. If there's issues with it, then we'll have to do the above thing and clear HLE too, by hand. > Furthermore, while grepping through the tree, I found >=20 > events/intel/lbr.c-267-static inline bool > lbr_from_signext_quirk_needed(void) > events/intel/lbr.c-268-{ > events/intel/lbr.c-269- int lbr_format =3D x86_pmu.intel_cap.lbr_format; > events/intel/lbr.c:270: bool tsx_support =3D boot_cpu_has(X86_FEATURE_HLE) = || > events/intel/lbr.c-271-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 boot_cpu_has(= X86_FEATURE_RTM); > events/intel/lbr.c-272- > events/intel/lbr.c-273- return !tsx_support && (lbr_desc[lbr_format] & > LBR_TSX); >=20 > which is going to need an adjustment to avoid applying the quirks on > non-broken hardware. When both HLE and RTM bits are cleared, that should still be correct, no? Or am I missing something? --=20 Regards/Gruss, Boris. SUSE Software Solutions Germany GmbH, GF: Felix Imend=C3=B6rffer, HRB 36809, = AG N=C3=BCrnberg