linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Fenghua Yu <fenghua.yu@intel.com>,
	Eduardo Habkost <ehabkost@redhat.com>,
	Ingo Molnar <mingo@redhat.com>, H Peter Anvin <hpa@zytor.com>,
	Ashok Raj <ashok.raj@intel.com>, Alan Cox <alan@linux.intel.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Rafael Wysocki <rafael.j.wysocki@intel.com>,
	Tony Luck <tony.luck@intel.com>,
	Ravi V Shankar <ravi.v.shankar@intel.com>,
	linux-kernel <linux-kernel@vger.kernel.org>, x86 <x86@kernel.org>,
	Vedvyas Shanbhogue <vedvyas.shanbhogue@intel.com>
Subject: Re: [PATCH v2 1/4] x86/split_lock: Enumerate #AC exception for split locked access feature
Date: Wed, 11 Jul 2018 12:59:24 -0700	[thread overview]
Message-ID: <ef07e047-e928-49a8-b08b-cb4c691db16a@intel.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1807102140050.1588@nanos.tec.linutronix.de>

On 07/10/2018 12:47 PM, Thomas Gleixner wrote:
> And please tell your hardware people that they should stop creating
> features which are not enumerated in one way or the other. That's just a
> pain all over the place. Boot code, kernel, virt, tools ....

Assuming it's too late to get CPUID or MSR enumeration... (I haven't
given up on this yet, btw)

How about we #define a Linux-defined X86_FEATURE_SPLIT_LOCK_AC (or
whatever) for now.  When the hardware that has this bit for real shows
up, we move the #define to the "correct" place, like if it is a part of
an existing cpufeature leaf.

We also do a new setcpuid= boot option that behaves like the existing
clearcpuid=.  That option is used by the obscure, specialized split lock
detectino users to set the software cpufeature bit.

That way, we can merged this code *with* CPUID detection, and the only
thing we have to do in the future is move the X86_FEATURE_SPLIT_LOCK_AC
define to a better place.

It might be nice to make the setcpuid= thing use strings instead of
numbers that _can_ change from kernel-to-kernel, but that's kinda an
implementation detail.  If we have strings, maybe we can start using
clearcpuid=pku instead of our endless list of (new) boot parameters like
nopku, nosmap, nosmep, etc...

  reply	other threads:[~2018-07-11 19:59 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-29 14:33 [PATCH v2 0/4] x86/split_lock: Enable #AC exception for split locked accesses Fenghua Yu
2018-06-29 14:33 ` [PATCH v2 1/4] x86/split_lock: Enumerate #AC exception for split locked access feature Fenghua Yu
2018-06-29 14:56   ` Dave Hansen
2018-06-29 16:23     ` Thomas Gleixner
2018-06-29 16:32       ` Dave Hansen
2018-07-04 20:07       ` Eduardo Habkost
2018-07-10 18:45         ` Fenghua Yu
2018-07-10 18:54           ` Dave Hansen
2018-07-10 19:47             ` Thomas Gleixner
2018-07-11 19:59               ` Dave Hansen [this message]
2018-07-12 20:00                 ` Thomas Gleixner
2018-06-29 14:33 ` [PATCH v2 2/4] x86/split_lock: Align x86_capability to unsigned long to avoid split locked access Fenghua Yu
2018-06-29 16:04   ` Dave Hansen
2018-06-29 16:35     ` Thomas Gleixner
2018-06-29 19:03       ` Fenghua Yu
2018-06-29 20:08         ` Thomas Gleixner
2018-06-29 20:38           ` Fenghua Yu
2018-06-29 20:48             ` Dave Hansen
2018-06-29 21:10               ` Fenghua Yu
2018-06-29 21:44               ` Thomas Gleixner
2018-06-30  0:00                 ` Fenghua Yu
2018-06-30  0:14                   ` Fenghua Yu
2018-06-30  6:23                     ` Thomas Gleixner
2018-07-02 12:18             ` Peter Zijlstra
2018-07-02 14:11               ` Fenghua Yu
2018-06-29 14:33 ` [PATCH v2 3/4] x86/split_lock: Handle #AC exception for split lock Fenghua Yu
2018-06-29 16:29   ` Dave Hansen
2018-06-29 16:33     ` Luck, Tony
2018-06-29 17:16       ` Fenghua Yu
2018-06-29 17:29         ` Dave Hansen
2018-06-29 17:39           ` Fenghua Yu
2018-06-29 17:47             ` Dave Hansen
2018-06-29 14:33 ` [PATCH v2 4/4] x86/split_lock: Disable #AC for split locked accesses Fenghua Yu
2018-06-29 16:31   ` Dave Hansen

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=ef07e047-e928-49a8-b08b-cb4c691db16a@intel.com \
    --to=dave.hansen@intel.com \
    --cc=alan@linux.intel.com \
    --cc=ashok.raj@intel.com \
    --cc=ehabkost@redhat.com \
    --cc=fenghua.yu@intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=ravi.v.shankar@intel.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=vedvyas.shanbhogue@intel.com \
    --cc=x86@kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).