From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mga05.intel.com ([192.55.52.43]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fJlP4-0007xP-2F for speck@linutronix.de; Fri, 18 May 2018 21:51:02 +0200 References: <20180518135457.GB18423@char.us.oracle.com> From: Tim Chen Message-ID: <1eb46f22-9115-7977-7631-9d8fcfc98447@linux.intel.com> Date: Fri, 18 May 2018 12:50:58 -0700 MIME-Version: 1.0 In-Reply-To: Subject: [MODERATED] Encrypted Message Content-Type: multipart/mixed; boundary="9yIb647lJG01SEBPjAbnUJYOl01n0aWRN"; protected-headers="v1" To: speck@linutronix.de List-ID: This is an OpenPGP/MIME encrypted message (RFC 4880 and 3156) --9yIb647lJG01SEBPjAbnUJYOl01n0aWRN Content-Type: text/rfc822-headers; protected-headers="v1" Content-Disposition: inline From: Tim Chen To: speck for Thomas Gleixner Subject: Re: Is: Sleep states ?Was:Re: SSB status - V18 pushed out --9yIb647lJG01SEBPjAbnUJYOl01n0aWRN Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 05/18/2018 07:29 AM, speck for Thomas Gleixner wrote: > On Fri, 18 May 2018, speck for Konrad Rzeszutek Wilk wrote: >> On Thu, May 17, 2018 at 10:53:28PM +0200, speck for Thomas Gleixner wr= ote: >>> Folks, >>> >>> we finally reached a stable state with the SSB patches. I've updated = all 3 >>> branches master/linux-4.16.y/linux-4.14.y in the repo and attached th= e >>> resulting git bundles. They merge cleanly on top of the current HEADs= of >>> the relevant trees. >>> >>> The lot survived light testing on my side and it would be great if ev= eryone >>> involved could expose it to their test scenarios. >>> >>> Thanks to everyone who participated in that effort (patches, review, >>> testing ...)! >> >> Yeey! Thank you. >> >> I was reading the updated Intel doc today (instead of skim reading it)= and it mentioned: >> >> "Intel recommends that the SSBD MSR bit be cleared when in a sleep sta= te on such processors." >=20 > Well, the same recommendation was for IBRS and the reason is that with = HT > enabled the other hyperthread will not be able to go full speed because= the > sleeping one vanished with IBRS set. SSBD works the same way. >=20 > " SW should clear [SSBD] when enter sleep state, just as is suggested f= or > IBRS and STIBP on existing implementations" >=20 > and that document says: >=20 > "Enabling IBRS on one logical processor of a core with Intel > Hyper-Threading Technology may affect branch prediction on other logic= al > processors of the same core. For this reason, software should disable = IBRS > (by clearing IA32_SPEC_CTRL.IBRS) prior to entering a sleep state (e.g= =2E, > by executing HLT or MWAIT) and re-enable IBRS upon wakeup and prior to= > executing any indirect branch." >=20 > So it's only a performance issue and not a fundamental problem to have = it > on when executing HLT/MWAIT >=20 > So we have two situations here: >=20 > 1) ssbd =3D on, i.e X86_FEATURE_SPEC_STORE_BYPASS_DISABLE >=20 > There it is irrelevant because both threads have SSBD set permanente= ly, > so unsetting it on HLT/MWAIT is not going to lift the restriction fo= r > the running sibling thread. And HLT/MWAIT is not going to be faster = by > unsetting it and then setting it on wakeup again.... >=20 > 2) SSBD via prctl/seccomp >=20 > Nothing to do there, because idle task does not have TIF_SSBD set so= it > never goes with SSBD set into HLT/MWAIT. >=20 > So I think we're good, but it would be nice if Intel folks would confir= m > that. Yes, we have thought about turning off SSBD in the mwait path earlier. Bu= t decided that it was unnecessary for the exact reasons Thomas mentioned. Thanks. Tim --9yIb647lJG01SEBPjAbnUJYOl01n0aWRN--