From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from p5492e61e.dip0.t-ipconnect.de ([84.146.230.30] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fC8tt-0007MV-AI for speck@linutronix.de; Fri, 27 Apr 2018 21:19:21 +0200 Date: Fri, 27 Apr 2018 21:19:20 +0200 (CEST) From: Thomas Gleixner Subject: Re: [PATCH v2] Linux Patch 1/1 In-Reply-To: Message-ID: References: <92c45587-5eb3-2421-6fc1-42e74a715e30@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Fri, 27 Apr 2018, speck for Tim Chen wrote: > On 04/27/2018 09:08 AM, speck for Thomas Gleixner wrote: > > Which would get rid of the static key because the only place where the > > mitigation mode and therefore the PRCTL enablement needs to be checked is > > the prctl itself. > > Okay, I'll take a crack with this approach. You have any suggestions > of dealing with AMD cpus which use a different msr (MSR_AMD64_LS_CFG) > and differnet bit depending on cpu model? > > I'm hoping I don't have to check for vendor in this code every time. Now you care about performance? Excuse me, but that just makes me laugh. The vendor check in the slow path is definitely way less horrible than a extra conditional _and_ a potentially pointless function call into a separate compilation unit in the hot path. > I was earlier thinking of using static key to segregate the vendor > code paths. So if I put in a static_cpu_has(X86_FEATURE_AMD_RDS) kind of > check here, will it be acceptable? Or is there already a static > key I can use to distinguish between intel and amd cpu? Not that I know of. But adding one should be simple enough and I assume that we might have other places where this would be useful. Thanks, tglx