Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932257AbeAHU5y (ORCPT + 1 other); Mon, 8 Jan 2018 15:57:54 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:51008 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756351AbeAHU5w (ORCPT ); Mon, 8 Jan 2018 15:57:52 -0500 Date: Mon, 8 Jan 2018 21:57:19 +0100 (CET) From: Thomas Gleixner To: Tom Lendacky cc: Andrew Cooper , bp@alien8.de, dwmw@amazon.co.uk, gregkh@linux-foundation.org, pjt@google.com, mingo@kernel.org, linux-kernel@vger.kernel.org, hpa@zytor.com, tim.c.chen@linux.intel.com, torvalds@linux-foundation.org, peterz@infradead.org, dave.hansen@intel.com, linux-tip-commits@vger.kernel.org Subject: Re: [tip:x86/pti] x86/cpu/AMD: Use LFENCE_RDTSC instead of MFENCE_RDTSC In-Reply-To: Message-ID: References: <20180105160756.23786.4220.stgit@tlendack-t1.amdoffice.net> <1b179b8b-6cc8-d736-81dc-2445be4baf02@citrix.com> <4d9a1f0d-a401-3f0f-9ee2-dd42f4b4716a@amd.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Mon, 8 Jan 2018, Tom Lendacky wrote: > So now I'm also concerned about setting the retpoline method and using > LFENCE as the speculation barrier. If we go back to the original > statement: > > - the hypervisor did not set the LFENCE to serializing on the host > - the hypervisor does not allow writing MSR_AMD64_DE_CFG > > It looks like I'll need to attempt to write MSR_AMD64_DE_CFG and then read > it back checking for whether MSR_F10H_DECFG_LFENCE_SERIALIZE has been set. > If the MSR can be read and the bit is set, then I can set RETPOLINE_AMD > (once those patches go in) and LFENCE_RDTSC. Otherwise, set (only) > MFENCE_RDTSC. This also means we need to use MFENCE as the speculation > barrier instead of LFENCE in this situation (another alternative added to > the __nospec_barrier() implementation). > > Does that sound right? Or does the "cannot prove that you run on bare > metal" mess this all up? I think that covers it. If the hypervisor would be trapping the read and then lying on the bit being set while it's not, that's really nothing you should care about at all. Thanks, tglx