From: Peter Zijlstra <peterz@infradead.org>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Borislav Petkov <bp@alien8.de>,
Thomas Gleixner <tglx@linutronix.de>,
Fenghua Yu <fenghua.yu@intel.com>, Ingo Molnar <mingo@redhat.com>,
H Peter Anvin <hpa@zytor.com>, Ashok Raj <ashok.raj@intel.com>,
Michael Chan <michael.chan@broadcom.com>,
Ravi V Shankar <ravi.v.shankar@intel.com>,
Ricardo Neri <ricardo.neri@intel.com>,
linux-kernel <linux-kernel@vger.kernel.org>, x86 <x86@kernel.org>
Subject: Re: [PATCH v3 08/10] x86/setcpuid: Add kernel option setcpuid
Date: Tue, 5 Feb 2019 09:48:57 +0100 [thread overview]
Message-ID: <20190205084857.GK17528@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <5c2f0af3-1740-f16b-6ff6-6bec6a325034@intel.com>
On Mon, Feb 04, 2019 at 12:46:30PM -0800, Dave Hansen wrote:
> So, the compromise we reached in this case is that Intel will fully
> document the future silicon architecture, and then write the kernel
> implementation to _that_. Then, for the weirdo deployments where this
> feature is not enumerated, we have the setcpuid= to fake the enumeration
> in software.
What user is _EVER_ going to use this? Nobody, I expect the answer to
be.
Is this some transient state; where a few (early) models will not have
the enumeration sorted but all later models will have it all neat and
tidy?
If so, we can easily do the FMS solution for this.
But a cmdline features thing is not something I can see anybody but
a limited set of developers ever using.
next prev parent reply other threads:[~2019-02-05 8:49 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-02 5:14 [PATCH v3 00/10] x86/split_lock: Enable #AC exception for split locked accesses Fenghua Yu
2019-02-02 5:14 ` [PATCH v3 01/10] x86/common: Align cpu_caps_cleared and cpu_caps_set to unsigned long Fenghua Yu
2019-02-02 5:14 ` [PATCH v3 02/10] drivers/net/b44: Align pwol_mask to unsigned long for better performance Fenghua Yu
2019-02-02 5:14 ` [PATCH v3 03/10] wlcore: Align reg_ch_conf_pending and tmp_ch_bitmap " Fenghua Yu
2019-02-02 5:14 ` [PATCH v3 04/10] x86/split_lock: Align x86_capability to unsigned long to avoid split locked access Fenghua Yu
2019-02-02 5:14 ` [PATCH v3 05/10] x86/clearcpuid: Support multiple clearcpuid options Fenghua Yu
2019-02-02 5:14 ` [PATCH v3 06/10] x86/clearcpuid: Support feature flag string in kernel option clearcpuid Fenghua Yu
2019-02-02 5:14 ` [PATCH v3 07/10] Change document for " Fenghua Yu
2019-02-02 5:14 ` [PATCH v3 08/10] x86/setcpuid: Add kernel option setcpuid Fenghua Yu
2019-02-04 17:49 ` Thomas Gleixner
2019-02-04 19:05 ` Dave Hansen
2019-02-04 19:57 ` Borislav Petkov
2019-02-04 20:46 ` Dave Hansen
2019-02-04 21:40 ` Borislav Petkov
2019-02-04 22:14 ` Fenghua Yu
2019-02-05 6:10 ` Borislav Petkov
2019-02-04 23:24 ` Dave Hansen
2019-02-05 6:18 ` Borislav Petkov
2019-02-05 16:46 ` Dave Hansen
2019-02-05 17:09 ` Peter Zijlstra
2019-02-05 8:57 ` Peter Zijlstra
2019-02-05 13:15 ` Peter Zijlstra
2019-02-05 8:48 ` Peter Zijlstra [this message]
2019-02-05 15:19 ` Dave Hansen
2019-02-05 15:43 ` Borislav Petkov
2019-02-05 18:26 ` Fenghua Yu
2019-02-05 17:04 ` Peter Zijlstra
2019-02-10 19:20 ` Thomas Gleixner
2019-02-11 19:16 ` Fenghua Yu
2019-02-12 13:37 ` Peter Zijlstra
2019-02-12 13:51 ` Thomas Gleixner
2019-02-12 16:48 ` Peter Zijlstra
2019-02-12 16:50 ` Dave Hansen
2019-02-12 17:52 ` Yu, Fenghua
2019-02-04 21:09 ` Fenghua Yu
2019-02-05 8:51 ` Peter Zijlstra
2019-02-05 15:21 ` Dave Hansen
2019-02-05 15:34 ` Peter Zijlstra
2019-02-02 5:14 ` [PATCH v3 09/10] x86/split_lock: Define #AC for split lock feature Fenghua Yu
2019-02-04 18:41 ` Dave Hansen
2019-02-04 18:45 ` Fenghua Yu
2019-02-04 19:00 ` Dave Hansen
2019-02-04 19:03 ` Fenghua Yu
2019-02-02 5:14 ` [PATCH v3 10/10] x86/split_lock: Handle #AC exception for split lock Fenghua Yu
2019-02-04 11:00 ` kbuild test robot
2019-02-04 14:43 ` kbuild test robot
2019-02-11 10:53 ` Ingo Molnar
2019-02-11 18:10 ` Fenghua Yu
2019-02-13 8:14 ` Ingo Molnar
2019-02-13 14:37 ` Yu, Fenghua
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=20190205084857.GK17528@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=ashok.raj@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.chan@broadcom.com \
--cc=mingo@redhat.com \
--cc=ravi.v.shankar@intel.com \
--cc=ricardo.neri@intel.com \
--cc=tglx@linutronix.de \
--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
Powered by JetHome