[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b0267bb2-7d1f-c1d6-cff8-addf358009b3@intel.com>
Date: Fri, 29 Jun 2018 07:56:40 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Fenghua Yu <fenghua.yu@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, H Peter Anvin <hpa@...or.com>
Cc: Ashok Raj <ashok.raj@...el.com>, Alan Cox <alan@...ux.intel.com>,
Peter Zijlstra <peterz@...radead.org>,
Rafael Wysocki <rafael.j.wysocki@...el.com>,
Tony Luck <tony.luck@...el.com>,
Ravi V Shankar <ravi.v.shankar@...el.com>,
linux-kernel <linux-kernel@...r.kernel.org>, x86 <x86@...nel.org>
Subject: Re: [PATCH v2 1/4] x86/split_lock: Enumerate #AC exception for split
locked access feature
On 06/29/2018 07:33 AM, Fenghua Yu wrote:
> +/* Detect feature of #AC for split lock by probing bit 29 in MSR_TEST_CTL. */
> +void detect_ac_split_lock(void)
> +{
> + u64 val, orig_val;
> + int ret;
> +
> + /* Attempt to read the MSR. If the MSR doesn't exist, reading fails. */
> + ret = rdmsrl_safe(MSR_TEST_CTL, &val);
> + if (ret)
> + return;
This is a bit fast and loose with how the feature is detected, which
might be OK, but can we call out why we are doing this, please?
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?
Powered by blists - more mailing lists