Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S965097AbeAJPre (ORCPT <rfc822;ralf@linux-mips.org> + 1 other);
        Wed, 10 Jan 2018 10:47:34 -0500
Received: from mx1.redhat.com ([209.132.183.28]:60960 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S932166AbeAJPrc (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 10 Jan 2018 10:47:32 -0500
Date: Wed, 10 Jan 2018 16:47:29 +0100
From: Andrea Arcangeli <aarcange@redhat.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Dave Hansen <dave.hansen@intel.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Jiri Kosina <jikos@kernel.org>,
        "asit.k.mallick" <asit.k.mallick@intel.com>,
        "Van De Ven, Arjan" <arjan.van.de.ven@intel.com>,
        Peter Zijlstra <peterz@infradead.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Linus Torvalds <torvalds@linuxfoundation.org>, x86@kernel.org,
        Borislav Petkov <bp@alien8.de>,
        Tim Chen <tim.c.chen@linux.intel.com>,
        Andi Kleen <ak@linux.intel.com>,
        Greg KH <gregkh@linuxfoundation.org>,
        Andy Lutomirski <luto@kernel.org>
Subject: Re: [patch RFC 5/5] x86/speculation: Add basic speculation control
 code
Message-ID: <20180110154729.GK9417@redhat.com>
References: <1515587384.22302.132.camel@infradead.org>
 <20180110124119.GG9706@redhat.com>
 <alpine.LRH.2.00.1801101343540.27010@gjva.wvxbf.pm>
 <20180110125710.GH9706@redhat.com>
 <1515589641.22302.145.camel@infradead.org>
 <alpine.DEB.2.20.1801101424180.1919@nanos>
 <20180110141047.GD9417@redhat.com>
 <1610a587-fe9e-28bd-dcd1-b9ec940c07ef@intel.com>
 <20180110151317.GI9417@redhat.com>
 <1515597857.22302.190.camel@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1515597857.22302.190.camel@infradead.org>
User-Agent: Mutt/1.9.2 (2017-12-15)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Wed, 10 Jan 2018 15:47:32 +0000 (UTC)
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 Wed, Jan 10, 2018 at 03:24:17PM +0000, David Woodhouse wrote:
> Since it achieves nothing? but to make userspace run slower, there's no
> need to?write it again on returning to userspace. It will perform that
> function just fine without doing so.

Ok, very glad we are on the same page now.

Note that as far as I can tell there was no way to answer the above
question by reading the spec.

You also explicitly used the word barrier in association with IBRS
before, but there was no word barrier in the aforementioned specs in
association with IBRS (every word barrier was always and only in
association with IBPB).

I hope this discussion helped clear the additional barrier semantics
of IBRS in more understandable way for the current/future upstream
code.

Thanks,
Andrea