[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4d597ddd-1be6-f903-ab28-e76a498ba652@intel.com>
Date: Tue, 15 May 2018 08:54:02 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Fenghua Yu <fenghua.yu@...el.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...e.hu>,
"H. Peter Anvin" <hpa@...ux.intel.com>,
Ashok Raj <ashok.raj@...el.com>,
Ravi V Shankar <ravi.v.shankar@...el.com>,
Tony Luck <tony.luck@...el.com>,
Rafael Wysocki <rafael.j.wysocki@...el.com>,
Arjan van de Ven <arjan@...radead.org>,
Alan Cox <alan@...ux.intel.com>, x86 <x86@...nel.org>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 01/15] x86/split_lock: Add CONFIG and enumerate #AC
exception for split locked access feature
On 05/15/2018 08:41 AM, Fenghua Yu wrote:
> On Tue, May 15, 2018 at 08:36:35AM -0700, Dave Hansen wrote:
>> On 05/14/2018 11:52 AM, Fenghua Yu wrote:
>>> +#include <linux/printk.h>
>>> +#include <asm/msr.h>
>>> +
>>> +static bool split_lock_ac_supported;
>> Was there a reason not to use an X86_FEATURE* bit for this?
> The feature is not enumerated in cpuid. It's detected by writing 1
> to bit 29 in MSR 0x33.
>
> So it can't fit in X86_FEATURE, right?
We have X86_FEATURE_*'s for lots of things, even software constructs
that have no representation in the hardware CPUID.
Powered by blists - more mailing lists