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

H. Peter Anvin
2025-12-15T04:26:47Z

On December 14, 2025 5:39:25 AM PST, David Laight <david.laight.linux@gmail.com> wrote:
>On Sun, 14 Dec 2025 09:46:48 +0100
>Ingo Molnar <mingo@kernel.org> 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.