From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id EF731C369D3 for ; Sun, 27 Apr 2025 09:50:24 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.969798.1358737 (Exim 4.92) (envelope-from ) id 1u8yeJ-00006v-VJ; Sun, 27 Apr 2025 09:50:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 969798.1358737; Sun, 27 Apr 2025 09:50:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1u8yeJ-00006o-SH; Sun, 27 Apr 2025 09:50:11 +0000 Received: by outflank-mailman (input) for mailman id 969798; Sun, 27 Apr 2025 09:50:10 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1u8yeI-0007cC-Dn for xen-devel@lists.xenproject.org; Sun, 27 Apr 2025 09:50:10 +0000 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 013f5cb5-234d-11f0-9eb3-5ba50f476ded; Sun, 27 Apr 2025 11:50:09 +0200 (CEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 784E661157; Sun, 27 Apr 2025 09:49:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E2390C4CEE3; Sun, 27 Apr 2025 09:50:03 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 013f5cb5-234d-11f0-9eb3-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745747407; bh=8UYVrDmaKV6ZZ3qAklvl94/hVHJqh5GIwBuL4dIJJTU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LNUFh+HV+LRgnlPShS8rXS7sdSbnkm7jbQkvCdQsHl+SntI9iCfZu/sITsPyhbxQP VxVG7pCTFrxhj2lsgxbjty+QQQUfryr9eRA9koIa29U19wCpHAhZZUoMF3g6dNaziW Nv9RG226Cx91ZCmPX1xL1EB7VB9OTb3sTaIPT+9QrLCaJAjylLeH4tqzse919IMCEn dLPiARw0uHyg45zc9QUJBD/RbN4rIYBlZ+o/PxX55rbbFkJciSe3Jau7DINL50lONy 6UzTYjOH4/st87qenWg4Mdd8Qo7nZjJlMjKVAK2vsoz6KgS/EbnH/Ea/txXkSFrGSP 8Wt7G1FYKHkCQ== Date: Sun, 27 Apr 2025 11:50:01 +0200 From: Ingo Molnar To: Linus Torvalds Cc: Arnd Bergmann , Arnd Bergmann , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Boris Ostrovsky , Alexander Usyskin , Greg Kroah-Hartman , Mateusz =?utf-8?Q?Jo=C5=84czyk?= , Mike Rapoport , Ard Biesheuvel , Peter Zijlstra , linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH] [RFC] x86/cpu: rework instruction set selection Message-ID: References: <20250425141740.734030-1-arnd@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: * Linus Torvalds wrote: > On Sat, 26 Apr 2025 at 11:59, Arnd Bergmann wrote: > > > > Right. With the current set of features, CMOV is almost the > > same as 686. My reasoning was that support for CMOV has a > > very clear definition, with the instruction either being > > available or not. > > Yeah, I don't think there's any reason to make CMOV a reason to drop support. > > It has questionable performance impact - I doubt anybody can measure > it - and the "maintenance burden" is basically a single compiler > flag. > > (And yes, one use in a x86 header file that is pretty questionable > too: I think the reason for the cmov is actually i486-only behavior > and we could probably unify the 32-bit and 64-bit implementation) > > Let's not drop Pentium support due to something as insignificant as > that. Agreed on that. Idea to require CMOV dropped. Note that the outcome of 486 removal will likely be that the few remaining community distros that still offer x86-32 builds are either already 686-CMOV-only (Debian), or are going to drop their 486 builds and keep their 686-CMOV-only builds (Gentoo and Archlinux32) by way of simple inertia. (There's an off chance that they'll change their 486 builds to 586, but I think dropping the extra complication and standardizing on 686 will be the most likely outcome.) No commercial distro builds x86-32 with a modern v6.x series kernel AFAICS. Anyway, I agree that the maintenance cost on the kernel side to build non-CMOV kernels is very low. Thanks, Ingo