public inbox for linux-s390@vger.kernel.org
 help / color / mirror / Atom feed
From: Jon Masters <jcm@redhat.com>
To: Jiri Kosina <jikos@kernel.org>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
	kvm@vger.kernel.org, Heiko Carstens <heiko.carstens@de.ibm.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Cornelia Huck <cohuck@redhat.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Marcus Meissner <meissner@suse.de>
Subject: Re: [PATCH 2/6] s390: implement nospec_[load|ptr]
Date: Wed, 17 Jan 2018 09:52:09 -0500	[thread overview]
Message-ID: <e269adc3-35ba-3ac9-1302-9211374f2d34@redhat.com> (raw)
In-Reply-To: <nycvar.YFH.7.76.1801171340460.11852@cbobk.fhfr.pm>

On 01/17/2018 07:41 AM, Jiri Kosina wrote:
> On Wed, 17 Jan 2018, Martin Schwidefsky wrote:
> 
>> Implement nospec_load() and nospec_ptr() for s390 with the new
>> gmb() barrier between the boundary condition and the load that
>> may not be done speculatively.

Thanks for the patches, Martin et al. I tested various earlier versions
and will run these latest ones through some tests and add a tested by.

> FWIW the naming seems to be changing constantly. The latest patchset from 
> Dan Williams [1] uses ifence_...().
> 
> [1] lkml.kernel.org/r/151586744180.5820.13215059696964205856.stgit@dwillia2-desk3.amr.corp.intel.com

This is getting a little silly. Not to bikeshed this to death, but
obviously gmb (what was that ever supposed to stand for, global?) was
the wrong name. We favored seb (speculative execution barrier), etc.
Still, "ifence"? What is that supposed to mean? That sounds very
architecture specific vs. what we're actually trying to ensure, which is
that we don't speculatively load a pointer.

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop

  reply	other threads:[~2018-01-17 14:52 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-17  9:48 [PATCH 0/6] s390: improve speculative execution handling Martin Schwidefsky
2018-01-17  9:48 ` [PATCH 1/6] s390/alternative: use a copy of the facility bit mask Martin Schwidefsky
2018-01-17 13:54   ` David Hildenbrand
2018-01-17 14:24   ` Cornelia Huck
2018-01-17  9:48 ` [PATCH 2/6] s390: implement nospec_[load|ptr] Martin Schwidefsky
2018-01-17 12:41   ` Jiri Kosina
2018-01-17 14:52     ` Jon Masters [this message]
2018-01-17 13:58   ` David Hildenbrand
2018-01-17 14:04     ` Christian Borntraeger
2018-01-17  9:48 ` [PATCH 3/6] s390: add options to change branch prediction behaviour for the kernel Martin Schwidefsky
2018-01-18  9:52   ` Cornelia Huck
2018-01-19  4:53   ` QingFeng Hao
2018-01-17  9:48 ` [PATCH 4/6] s390: add system call to run tasks with modified branch prediction Martin Schwidefsky
2018-01-17 10:03   ` Florian Weimer
2018-01-17 10:05     ` Paolo Bonzini
2018-01-17 11:14     ` Christian Borntraeger
2018-01-17 11:50       ` Paolo Bonzini
2018-01-17 11:55       ` Martin Schwidefsky
2018-01-17 13:25         ` Heiko Carstens
2018-01-17  9:48 ` [PATCH 5/6] KVM: s390: wire up seb feature Martin Schwidefsky
2018-01-17 11:18   ` Christian Borntraeger
2018-01-17 11:22     ` Paolo Bonzini
2018-01-17 11:28       ` Christian Borntraeger
2018-01-17 11:29         ` Christian Borntraeger
2018-01-17 11:32           ` Paolo Bonzini
2018-01-17 11:33   ` David Hildenbrand
2018-01-17 11:39     ` Christian Borntraeger
2018-01-17 13:44   ` [PATCH v2] KVM: s390: wire up bpb feature Christian Borntraeger
2018-01-17 13:51     ` David Hildenbrand
2018-01-17 21:43       ` Christian Borntraeger
2018-01-18  6:27         ` Martin Schwidefsky
2018-01-18  9:59     ` Cornelia Huck
2018-01-18 10:09       ` Christian Borntraeger
2018-01-17  9:48 ` [PATCH 6/6] s390: scrub registers on kernel entry and KVM exit Martin Schwidefsky
2018-01-19  6:29   ` QingFeng Hao
2018-01-19  7:57     ` Christian Borntraeger
2018-01-19  8:27       ` QingFeng Hao
2018-01-17 12:00 ` [PATCH 0/6] s390: improve speculative execution handling Cornelia Huck
2018-01-17 12:05   ` Christian Borntraeger
2018-01-17 13:29 ` Greg Kroah-Hartman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e269adc3-35ba-3ac9-1302-9211374f2d34@redhat.com \
    --to=jcm@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=jikos@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=meissner@suse.de \
    --cc=pbonzini@redhat.com \
    --cc=schwidefsky@de.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox