[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.1902041745370.3006@nanos.tec.linutronix.de>
Date: Mon, 4 Feb 2019 17:49:06 +0000 (GMT)
From: Thomas Gleixner <tglx@...utronix.de>
To: Fenghua Yu <fenghua.yu@...el.com>
cc: Ingo Molnar <mingo@...hat.com>, H Peter Anvin <hpa@...or.com>,
Dave Hansen <dave.hansen@...el.com>,
Ashok Raj <ashok.raj@...el.com>,
Peter Zijlstra <peterz@...radead.org>,
Michael Chan <michael.chan@...adcom.com>,
Ravi V Shankar <ravi.v.shankar@...el.com>,
Ricardo Neri <ricardo.neri@...el.com>,
linux-kernel <linux-kernel@...r.kernel.org>, x86 <x86@...nel.org>
Subject: Re: [PATCH v3 08/10] x86/setcpuid: Add kernel option setcpuid
On Fri, 1 Feb 2019, Fenghua Yu wrote:
> On some platforms, a feature (e.g. #AC for split lock) may not be
> enumerated by CPUID or non architectural way in IA32_CORE_CAPABILITY.
> To enable the feature on the platforms, a new kernel option setcpuid
> is added.
>
> The feature is defined in cpufeatures.h. The kernel option setcpuid
> takes either feature bit or cpu cap flag corresponding to the feature.
> The format of the option:
> setcpuid=<feature bit>
> setcpuid=<feature capability flag>
>
> Check cpufeatures.h for valid feature bit numbers and check capflags.c
> or /proc/cpuinfo for valid feature capability flags.
>
> Enabling multiple features are supported.
>
> Please note kernel may malfunction if some features are enabled by
> the option.
>
> This option behaves like existing kernel option clearcpuid.
No it does NOT. clearcpuid allows to disable things.
This allows to enable random CPUID bits without any sanity checking. Not
going to happen. We made it clear in the past that functionality needs to
be detectable by enumeration. We do quirks for broken crap, but this is
just not how it works.
Thanks,
tglx
Powered by blists - more mailing lists