From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from terminus.zytor.com (terminus.zytor.com [198.137.202.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 230811EDA2C for ; Mon, 15 Dec 2025 04:26:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.136 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765772811; cv=none; b=p42zeIMkpo0E+PxLOuXnBIhlO+3RArRCNtNlAXEnqLa9eaYSK5TgcUDhBgBg7JdLTFWZBci8VaRI7CgJue1B8xX1t8BkZIOufydoRc31pMgnqRxA+cccX4JCz7dCX/wUfsJzhWJHoW2TG6NeVgcOwOyMrvoIj128feWbDtw4Qeg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765772811; c=relaxed/simple; bh=WivmHL/r2cI49oQN8Ss0ZcBNCRjz9SwCa13YjhxRLtk=; h=Date:From:To:CC:Subject:In-Reply-To:References:Message-ID: MIME-Version:Content-Type; b=RutcIYM5mYuoF7yKfO2h3FrupScUTb4dwV8//jXIwX71jJa/RS6fj0Onz0kgMfueUYrtwfMpijYLmXl6fLy/k+aYKz3tFVvu4y56xBPniEUyZe4Q2uxL65OVjj21WcT/5UTASQsOZn1DDZha0kO26UFM+15YJ0Ob7bcLVkL13Hw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com; spf=pass smtp.mailfrom=zytor.com; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b=hL46B2v4; arc=none smtp.client-ip=198.137.202.136 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=zytor.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b="hL46B2v4" Received: from ehlo.thunderbird.net (c-76-133-66-138.hsd1.ca.comcast.net [76.133.66.138]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 5BF4Mg7K2305822 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sun, 14 Dec 2025 20:22:42 -0800 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 5BF4Mg7K2305822 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2025112201; t=1765772563; bh=redrtH9snMFQJgwkgZ86/MURyyXcKtR30MhBjeDf0BY=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=hL46B2v4fhl+iwSAQOREKENKvBsabvpanGPOQC3g6h1kFcW2ERmnAp2xTnn1Iu0y7 R7RsMzaiD1pHLjH9CAXG1PFhns3zu1nNV9NCq2bgjX87wNj0Df4kJ62OPgugmqmoQK NlxaK+KEHD/EA4mdfznvjceYBOM4Yq0DVDvaJIatZV+9oSl8kMjyZu4TCN3jJou6Et sP5tw4BJU71M3OjVpnB7QaHo1TZJIhPTkYILcPQVtoUlqyfxHLxfNGoMyB78L7tVaR rQZc1tv3FBRmQ0h+mfOFZB0wkxUHN9bxk/BiJI2a99tAtnsQ0bDn8RtNT/wZBH20pq 93qOv9ng4GZlw== Date: Sun, 14 Dec 2025 20:22:40 -0800 From: "H. Peter Anvin" To: David Laight , Ingo Molnar CC: linux-kernel@vger.kernel.org, "Ahmed S . Darwish" , Andrew Cooper , Ard Biesheuvel , Arnd Bergmann , Borislav Petkov , Dave Hansen , John Ogness , Linus Torvalds , Peter Zijlstra , Thomas Gleixner Subject: =?US-ASCII?Q?Re=3A_=5BPATCH_-v3_0/15=5D_x86=3A_Remove_su?= =?US-ASCII?Q?pport_for_TSC-less_and_CX8-less_CPUs?= User-Agent: K-9 Mail for Android In-Reply-To: <20251214133925.1e80f851@pumpkin> References: <20251214084710.3606385-1-mingo@kernel.org> <20251214133925.1e80f851@pumpkin> Message-ID: <83CCCEC4-D85F-466C-AC5E-CF0F7722668A@zytor.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On December 14, 2025 5:39:25 AM PST, David Laight wrote: >On Sun, 14 Dec 2025 09:46:48 +0100 >Ingo Molnar wrote: > >>=2E=2E=2E >>=20 >> Original -v1 announcement: >>=20 >> 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=2E This compatibility glue is some= times >> even causing problems that people spend time to resolve, which time cou= ld >> be spent on other things=2E >>=20 >> As Linus recently remarked: >>=20 >> > I really get the feeling that it's time to leave i486 support behind= =2E >> > There's zero real reason for anybody to waste one second of >> > development effort on this kind of issue=2E =20 >>=20 >> This series increases minimum kernel support features to include TSC an= d >> CX8 (CMPXCHG8B) hardware support, which removes 486 (and derivatives) s= upport >> and early-586 (and derivatives) support=2E > >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=2E > I think that is 'Pentium Pro' and 'K7' rather than 'Pentium' and 'K5'= =2E > That simplifies some asm code=2E > 'masked' user access would really need it (and a guard page)=2E > The 'long nop' get added at the same time=2E > It is also (almost certainly) new enough that the 'bit scan' instructi= ons > are guaranteed to leave the the destination unchanged if the source is > zero (dropping just 486 may be enough for that)=2E > >Moving the minimum cpu to P-Pro now will probably save another similar >change in the near future=2E > > David There is a check in the BIOS real-mode code to print an error message=2E I= f it gets invoked any other way (directly in protected mode) it will almost= certainly crash=2E Please consider the cost/benefit trade-off when it comes to dropping suppo= rt; if the cost is small enough it doesn't matter much=2E Simplifying a sma= ll number of well-localized routines isn't a big enough deal, really=2E=20 In general, make sure that the appropriate X86_REQUIRED_FEATURE flags in K= config=2Ecpufeature get set =E2=80=93 that way the detect code and other ch= ecking code will work correctly=2E