From: Thomas Gleixner <tglx@linutronix.de>
To: Dave Hansen <dave.hansen@intel.com>
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: Tue, 10 Jul 2018 21:47:26 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.21.1807102140050.1588@nanos.tec.linutronix.de> (raw)
In-Reply-To: <ea23cde0-f999-0ed8-a3bc-e798511467bd@intel.com>
On Tue, 10 Jul 2018, Dave Hansen wrote:
> On 07/10/2018 11:45 AM, Fenghua Yu wrote:
> > On Wed, Jul 04, 2018 at 05:07:42PM -0300, Eduardo Habkost wrote:
> >> On Fri, Jun 29, 2018 at 06:23:35PM +0200, Thomas Gleixner wrote:
> >>> On Fri, 29 Jun 2018, Dave Hansen wrote:
> >>>> Is this MSR not really model-specific? Is it OK to go poking at it on
> >>>> all x86 variants? Or, do we at _least_ need a check for Intel cpus in here?
> >>>
> >>> That definitely needs a vendor check. Also the whole code needs to be
> >>> compiled out if CONFIG_INTEL=n.
> >>>
> >>> Aside of that this wants to be enumerated. CPUID or MISC_FEATURES and not
> >>> this guess work detection logic. Why do I have to ask for that for every
> >>> other new feature thingy?
> >>
> >> Yes, please. KVM hosts normally expect guests to not touch MSRs
> >> unless we explicitly tell them the MSR is available (normally
> >> through CPUID). This is important to ensure live migration
> >> between different host kernel versions works reliably.
> >
> > The problem is the hardware design for the feature is complete. The
> > hardware designer cannot change the feature enumeration to CPUID or
> > MISC_FEATURES.
Setting a fricking bit in a CPUID leaf or in a MSR cannot be done anymore?
That's just hilarious.
> Let's be honest, though. That's not *hardware* design; that is a
> microcode update. We've seen what microcode updates can do _very_
> clearly with all the security issues. We (Intel) can surely fix this if
> sufficiently motivated. No?
Amen to that.
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 ....
Thanks,
tglx
next prev parent reply other threads:[~2018-07-10 19:47 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 [this message]
2018-07-11 19:59 ` Dave Hansen
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=alpine.DEB.2.21.1807102140050.1588@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=alan@linux.intel.com \
--cc=ashok.raj@intel.com \
--cc=dave.hansen@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=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).