Re: [PATCH -v3 0/15] x86: Remove support for TSC-less and CX8-less CPUs

[H. Peter Anvin]

On December 14, 2025 5:39:25 AM PST, David Laight <david.laight.linux@xxxxxxxxx> wrote:
>On Sun, 14 Dec 2025 09:46:48 +0100
>Ingo Molnar <mingo@xxxxxxxxxx> wrote:
>
>>...
>> 
>> Original -v1 announcement:
>> 
>> In the x86 architecture we have various complicated hardware emulation
>> facilities on x86-32 to support ancient 32-bit CPUs that very very few
>> people are using with modern kernels. This compatibility glue is sometimes
>> even causing problems that people spend time to resolve, which time could
>> be spent on other things.
>> 
>> As Linus recently remarked:
>> 
>>  > I really get the feeling that it's time to leave i486 support behind.
>>  > There's zero real reason for anybody to waste one second of
>>  > development effort on this kind of issue.  
>> 
>> This series increases minimum kernel support features to include TSC and
>> CX8 (CMPXCHG8B) hardware support, which removes 486 (and derivatives) support
>> and early-586 (and derivatives) support.
>
>Two questions:
>
>1) What happens if you try to boot the kernel on an old system?
>   Is there an early check that makes it fail 'moderately gracefully'?
>
>2) Is it worth also dropping support for cpu that don't support CMOV.
>   I think that is 'Pentium Pro' and 'K7' rather than 'Pentium' and 'K5'.
>   That simplifies some asm code.
>   'masked' user access would really need it (and a guard page).
>   The 'long nop' get added at the same time.
>   It is also (almost certainly) new enough that the 'bit scan' instructions
>   are guaranteed to leave the the destination unchanged if the source is
>   zero (dropping just 486 may be enough for that).
>
>Moving the minimum cpu to P-Pro now will probably save another similar
>change in the near future.
>
>	David

There is a check in the BIOS real-mode code to print an error message. If it gets invoked any other way (directly in protected mode) it will almost certainly crash.

Please consider the cost/benefit trade-off when it comes to dropping support; if the cost is small enough it doesn't matter much. Simplifying a small number of well-localized routines isn't a big enough deal, really. 

In general, make sure that the appropriate X86_REQUIRED_FEATURE flags in Kconfig.cpufeature get set – that way the detect code and other checking code will work correctly.