Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S932257AbeAHU5y (ORCPT <rfc822;ralf@linux-mips.org> + 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
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 8 Jan 2018 15:57:52 -0500
Date: Mon, 8 Jan 2018 21:57:19 +0100 (CET)
From: Thomas Gleixner <tglx@linutronix.de>
To: Tom Lendacky <thomas.lendacky@amd.com>
cc: Andrew Cooper <andrew.cooper3@citrix.com>, 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: <b950e80b-e3a7-3395-8f22-74adbe91965d@amd.com>
Message-ID: <alpine.DEB.2.20.1801082155380.2253@nanos>
References: <20180105160756.23786.4220.stgit@tlendack-t1.amdoffice.net> <tip-0bf17c102177d5da9363bf8b1e4704b9996d5079@git.kernel.org> <alpine.DEB.2.20.1801081105120.1735@nanos> <1b179b8b-6cc8-d736-81dc-2445be4baf02@citrix.com> <alpine.DEB.2.20.1801081208500.1735@nanos>
 <4d9a1f0d-a401-3f0f-9ee2-dd42f4b4716a@amd.com> <alpine.DEB.2.20.1801081611180.1735@nanos> <b950e80b-e3a7-3395-8f22-74adbe91965d@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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Return-Path: <linux-kernel-owner@vger.kernel.org>

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