Re: [PATCH 13/15] x86/cpu: Make CONFIG_X86_CX8 unconditional

["Arnd Bergmann" <arnd@kernel.org>]

On Sun, Apr 27, 2025, at 11:25, Ingo Molnar wrote:
> * Arnd Bergmann <arnd@kernel.org> wrote:
>> On Fri, Apr 25, 2025, at 17:15, H. Peter Anvin wrote:
>> 
>> I now found that both Debian 12 and gcc 11 changed their definition
>> if 686 to actually require nopl for Indirect branch tracking 
>> (-fcf-protection) in user space, as discussed in
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104713
>> 
>> So even if it makes sense for GeodeLX specific kernel to use CMOV,
>> any general-purpose i686 distro would still want to enable IBT
>> in userspace to gain IBT on Tiger Lake and newer 64-bit CPUs.
>
> And the kernel Debian 12 uses is a "686" one:
>
>   ./pool/main/l/linux-signed-i386/linux-image-6.1.0-32-686_6.1.129-1_i386.deb
>   ./pool/main/l/linux-signed-i386/linux-image-686_6.1.129-1_i386.deb
>
> and the kernel is set to CONFIG_MGEODE_LX=y:
>
>   $ grep CONFIG_MGEODE_LX ./boot/config-6.1.0-32-686
>   CONFIG_MGEODE_LX=y
>
> ... which CPU has CMOV support:
>
>   config X86_CMOV
>         def_bool y
>         depends on (MK7 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || 
> MPENTIUMII || M686 || MVIAC3_2 || MVIAC7 || MCRUSOE || MEFFICEON || 
> MATOM || MGEODE_LX || X86_64)                                           
>                                                                         
>                                                                         
>                                                 ^^^^^^^^^
> So I'd argue that the kernel's x86-32 CPU support cutoff should match 
> the i386 CPU support cutoff of the Debian i386 installer.

I think this misses a few other bits of information, some of which
we already mentioned in this thread:

- Debian 13 no longer has any 32-bit kernel, so debian-i686 is
  primarily targeted at running on 64-bit kernels for memory
  constrained environments.

- Debian 12 started requiring NOPL in userspace, which is not
  supported on GeodeLX (or Crusoe), the kernel option should have
  been changed to M686 instead but was accidentally left at
  MGEODE_LX, so the kernel still works, but userspace doesn't.

- Anyone running Linux on an i586 machine likely already wants
  a custom kernel, regardless what the distros provide. This
  is especially true for the embedded targets.

> Survey of other distros:
>
>  - Fedora dropped x86-32 with Fedora 31, almost 5 years ago.
>
>  - Ubuntu dropped x86-32 after 18 LTS, more than 5 years ago. The LTS 
>    kernel is v5.6 based.
>
>  - Arch Linux dropped i686 support even earlier than that, the 
>    spin-off-community project of archlinux32.org has 486 and 686 
>    variants. 686 variant includes CMOV.
>
>  - Gentoo has an 'x86' variant with 486 and 686 stages. 686 stage 
>    includes CMOV.
>
> Ie. I think we can also make CMOV a hard requirement, and keep support 
> for all family 5 CPUs that have CMOV and have a chance to boot current 
> 32-bit distros. Even distros that had 486 builds have 686 variants that 
> should still work.
>
> I.e. remove support for M586MMX, M586TSC, MCYRIXIII, MGEODEGX1 and MK6 
> as well, these don't have CMOV support and won't even boot i386 Debian 
> 12.
>
> Summary, the plan would be to remove support for the following pre-CMOV 
> CPUs (the ones not yet in this series are marked 'NEW'):
>
>   M486
>   M486SX
>   M586
>   M586MMX         # NEW
>   M586TSC         # NEW
>   MCYRIXIII       # NEW
>   MELAN
>   MGEODEGX1       # NEW
>   MK6             # NEW
>   MWINCHIP3D
>   MWINCHIPC6

This would also mean dropping support for the pre-2015 Intel Quark
and DM&P Vortex86DX/DX2/MX/EX that never had a custom CONFIG_Mxxxx
option but are still relevant to some degree.
I think that would be a mistake. 

> And to keep these:
>
>   M686
>   MATOM
>   MCRUSOE
>   MEFFICEON
>   MGEODE_LX
>   MK7
>   MPENTIUM4
>   MPENTIUMII
>   MPENTIUMIII
>   MPENTIUMM
>   MVIAC3_2
>   MVIAC7

As Linus said, overall they are barely different from the
first group, and they are just as obsolete, only Atom and
Vortex86DX3/EmKore are less than 20 years old.

Here are some alternatives I like better than dropping i586:

a) keep my patch with an new bool option to pick between
   i586 and i686 targets, by any name.

b) always build with -march=i586 and leave only the -mtune
   flags; see if anyone cares enough to even benchmark
   and pick one of the other options if they can show
   a meaningful regression over -march=i686 -mtune=

c) keep the outcome of your v1 series, dropping only
   pre-i586 support, and leave my patch out. No change here,
   so at least no regression potential.

d) use -march=i686 (plus -mtune=) for normal builds, but
   keep support for the older cores guarded by
   X86_EXTENDED_PLATFORM or CONFIG_EXPERT, use -march=i586
   if at least one of those platforms is selected.

      Arnd