Message-ID: <B0D2F96E-F090-4D60-94B5-9FAD3536A4BD@zytor.com>
Date: Sun, 27 Apr 2025 14:26:24 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Arnd Bergmann <arnd@...nel.org>, Ingo Molnar <mingo@...nel.org>
CC: linux-kernel@...r.kernel.org, "Ahmed S . Darwish" <darwi@...utronix.de>,
        Andrew Cooper <andrew.cooper3@...rix.com>,
        Ard Biesheuvel <ardb@...nel.org>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        John Ogness <john.ogness@...utronix.de>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 13/15] x86/cpu: Make CONFIG_X86_CX8 unconditional

On April 27, 2025 10:32:14 AM PDT, Arnd Bergmann <arnd@...nel.org> wrote:
>On Sun, Apr 27, 2025, at 11:25, Ingo Molnar wrote:
>> * Arnd Bergmann <arnd@...nel.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

Interesting. They really should be using x32 for that application...

Powered by blists - more mailing lists