Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 19 Jan 2018 16:47:42 +0100
From:   Andrea Arcangeli <aarcange@redhat.com>
To:     "Van De Ven, Arjan" <arjan.van.de.ven@intel.com>
Cc:     Andy Lutomirski <luto@kernel.org>,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        Paolo Bonzini <pbonzini@redhat.com>,
        "Hansen, Dave" <dave.hansen@intel.com>,
        Peter Zijlstra <peterz@infradead.org>,
        David Woodhouse <dwmw2@infradead.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        LKML <linux-kernel@vger.kernel.org>,
        "Raj, Ashok" <ashok.raj@intel.com>,
        Tim Chen <tim.c.chen@linux.intel.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Greg KH <gregkh@linuxfoundation.org>,
        Andi Kleen <ak@linux.intel.com>,
        "Williams, Dan J" <dan.j.williams@intel.com>,
        "Nakajima, Jun" <jun.nakajima@intel.com>,
        "Mallick, Asit K" <asit.k.mallick@intel.com>,
        Jason Baron <jbaron@akamai.com>
Subject: Re: [PATCH 23/35] x86/speculation: Add basic speculation control code
Message-ID: <20180119154742.GA24935@redhat.com>
References: <20180118140152.830682032@infradead.org>
 <20180118163745.t5nmwdr53wjsl7o5@treble>
 <73a5735a-6a5b-0e0f-1f0b-e7cd955880d2@intel.com>
 <a0308ee6-959a-0a78-9205-8de0a60948ac@redhat.com>
 <20180118182431.xvmk6kzxpzu43b43@treble>
 <20180118190842.GA14136@redhat.com>
 <CALCETrU9Xa6pBd-WuQ9S1s32f7Nb=p9eHEAv7oixf+vZa18ETg@mail.gmail.com>
 <20180119014105.GD14136@redhat.com>
 <CALCETrWKjCtML_7m3oa7gQW6sM7LQB2A1Fh_kqKkQu6jF0uimg@mail.gmail.com>
 <0575AF4FD06DD142AD198903C74E1CC87A5E9136@ORSMSX103.amr.corp.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0575AF4FD06DD142AD198903C74E1CC87A5E9136@ORSMSX103.amr.corp.intel.com>
User-Agent: Mutt/1.9.2 (2017-12-15)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, Jan 19, 2018 at 04:15:33AM +0000, Van De Ven, Arjan wrote:
> there is no such guarantee. Some of the IBRS implementations will
> actually flush rather than disable, or flush parts and disable other
> parts.

To me it helps in order to memorize the spec to understand why the
spec is the way it is.

I tried to help explaining some of that, but I notice that I created
more confusion... I never intended IBPB can be skipped in user to user
switches if leaving IBRS set in userland, that's not what we do and it
wouldn't be ok with certain smarter CPUs.

> yes the wording is a bit cryptic, but it's also very explicit about
> what it covers (and the rest is not covered!) and had to allow a few
> different implementations unfortunately.

We already follow the spec to the letter and we only depend on what is
covered there.

Surely the specs already explain everything better than I could ever
do, so if anything wasn't clear in the two previous emails where I
failed to explain the difference between setting or leaving IBRS set
in userland (ibrs_user) and setting or leaving STIBP set in userland
(stibp_user) you'll find all answers in the very explicit spec per
above quote.

Thanks,
Andrea