Message-Id: <d2b0e71c-e79b-40d6-8693-3202cd894d66@app.fastmail.com>
Date: Sat, 26 Apr 2025 20:58:59 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Ingo Molnar" <mingo@...nel.org>, "Arnd Bergmann" <arnd@...nel.org>
Cc: "Thomas Gleixner" <tglx@...utronix.de>, "Ingo Molnar" <mingo@...hat.com>,
 "Borislav Petkov" <bp@...en8.de>,
 "Dave Hansen" <dave.hansen@...ux.intel.com>, x86@...nel.org,
 "H. Peter Anvin" <hpa@...or.com>, "Juergen Gross" <jgross@...e.com>,
 "Boris Ostrovsky" <boris.ostrovsky@...cle.com>,
 "Alexander Usyskin" <alexander.usyskin@...el.com>,
 "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
 Mateusz Jończyk <mat.jonczyk@...pl>,
 "Mike Rapoport" <rppt@...nel.org>, "Ard Biesheuvel" <ardb@...nel.org>,
 "Peter Zijlstra" <peterz@...radead.org>, linux-kernel@...r.kernel.org,
 xen-devel@...ts.xenproject.org,
 "Linus Torvalds" <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] [RFC] x86/cpu: rework instruction set selection

On Sat, Apr 26, 2025, at 11:08, Ingo Molnar wrote:
> * Arnd Bergmann <arnd@...nel.org> wrote:
>
> While the simplification is nice on its face, this looks messy:
>
>>  
>>  config X86_PAE
>>  	bool "PAE (Physical Address Extension) Support"
>> -	depends on X86_32 && X86_HAVE_PAE
>> +	depends on X86_32 && X86_CMOV
>
> Coupling CMOV to PAE ... :-/

Right. With the current set of features, CMOV is almost the
same as 686. My reasoning was that support for CMOV has a
very clear definition, with the instruction either being
available or not.

When the M686/MPENTIUMII/MK6/... options are just optimization
levels rather than selecting an instruction set, X86_PAE
can't depend on those any more. An easy answer here would be
to not have X86_PAE depend on anything, but instead make it
force X86_MINIMUM_CPU_FAMILY=6.

>> +config X86_CMOV
>> +	bool "Require 686-class CMOV instructions" if X86_32
>> +	default y
>>  	help
>> -	  This is the processor type of your CPU. This information is
>> -	  used for optimizing purposes. In order to compile a kernel
>> -	  that can run on all supported x86 CPU types (albeit not
>> -	  optimally fast), you can specify "586" here.
>> +	  Most x86-32 processor implementations are compatible with
>> +	  the the CMOV instruction originally added in the Pentium Pro,
>> +	  and they perform much better when using it.
>> +
>> +	  Disable this option to build for 586-class CPUs without this
>> +	  instruction. This is only required for the original Intel
>> +	  Pentium (P5, P54, P55), AMD K6/K6-II/K6-3D, Geode GX1 and Via
>> +	  CyrixIII/C3 CPUs.
>
> Very few users will know anything about CMOV.
>
> I'd argue the right path forward is to just bite the bullet and remove 
> non-CMOV support as well, that would be the outcome *anyway* in a few 
> years. That would allow basically a single 'modern' 32-bit kernel that 
> is supposed to boot on every supported CPU. People might even end up 
> testing it ... ;-)

That would be a much more drastic change than requiring CX8
and TSC, which were present on almost all Socket 7 CPUs and
all embedded cores other than Elan and Vortex86SX.

CMOV is missing not just on old Socket 5/7 CPUs (Pentium
MMX, AMD K6, Cyrix MII) but also newer embedded Via C3, Geode GX
and Vortex86DX/MX/EX/DX2. The replacement Nehemiah (2003), GeodeLX
(2005) and Vortex86DX3/EX2 (2015!) have CMOV, but the old ones
were sold alongside them for years, and some of the 586-class
Vortex86 products are still commercially available.

There is a good chance that we could just not use CMOV and only
build 586-compatible kernels without anyone caring about the
performance difference. There is not much to gain here either
though, as the cost of supporting both 586-class and 686-class
builds is rather small: there is a compiler flag, a boot time
check and microoptimziation in ffs/fls.

     Arnd

Powered by blists - more mailing lists