linux-kernel - Re: [PATCH] [RFC] x86/cpu: rework instruction set selection

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wh=TUsVv6xhtzYsWJwJggrjyOfYT3kBu+bHtoYLK0M9Xw@mail.gmail.com>
Date: Sat, 26 Apr 2025 12:24:37 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Arnd Bergmann <arnd@...db.de>
Cc: Ingo Molnar <mingo@...nel.org>, Arnd Bergmann <arnd@...nel.org>, 
	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
Subject: Re: [PATCH] [RFC] x86/cpu: rework instruction set selection

On Sat, 26 Apr 2025 at 11:59, Arnd Bergmann <arnd@...db.de> wrote:
>
> 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.

Yeah, I don't think there's any reason to make CMOV a reason to drop support.

It has questionable performance impact - I doubt anybody can measure
it - and the "maintenance burden" is basically a single compiler flag.

(And yes, one use in a x86 header file that is pretty questionable
too: I think the reason for the cmov is actually i486-only behavior
and we could probably unify the 32-bit and 64-bit implementation)

Let's not drop Pentium support due to something as insignificant as that.

Particularly as the only half-way "modern" use of the Pentium core is
actually the embedded cores (ie old atoms and clones).

We have good reasons to drop i486 (and the "fake Pentium" cores that
weren't). We _don't_ have good reason to drop Pentium support, I
think.

>  An easy answer here would be
> to not have X86_PAE depend on anything, but instead make it
> force X86_MINIMUM_CPU_FAMILY=6.

Make it so.

          Linus