Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp264729pxb; Mon, 13 Sep 2021 18:49:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwfezGpktfGuxryyTFQuhf6Gli18bN/L0am9uiFEIzgZ0uUx2z2+B0d7x58vQahYlFdVKxc X-Received: by 2002:a17:906:6445:: with SMTP id l5mr15430661ejn.194.1631584143143; Mon, 13 Sep 2021 18:49:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631584143; cv=none; d=google.com; s=arc-20160816; b=v1fwF+G3+eAuCQdLslnqupzi1mdvWSc4zPR0i1f5j4WHte3d5xjOEx1VaMBrIIsBPm jl5J2RD35DipINx3hpgFFq8V7Vkv1UTU8xhhnEVn3e1Rz21CmphaTvd6YNEFfQC/zWIL LW3juWdWtiEA0Jxgd1FhWdwrRekkDQ8/8vXxVTYm/Trx+P7J/kE7jfKemQoFoQZPV85H jlBVVYTo71xTMwuZxWTd4o1KBurElLgYQ+rUALEmWTcodbknKs3BNnJMqOo7jQp8lgjK bcQlrlJ0mC9BwQBYNtVnsqz3kOqS0grtPFpCgzeNs3hFP0DH74YwlEmch1xH2hALUPMN T+UQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:robot-unsubscribe :robot-id:message-id:mime-version:references:in-reply-to:cc:subject :to:reply-to:sender:from:dkim-signature:dkim-signature:date; bh=rvh2aNpgEjB+qu7KHhTSh9RhV+DtQghdR7Dqdgn8iro=; b=SbKgl3q2uYbtc+TViRLqC9aAW+frsOmWmjvqvvuh7sVFUsBG/iijlDApnIUpGVYPD9 fxuPzqs54te+EvBym4r3VFsAT6742UTHZpIqIiYfDwKtk5TmEPrUf8AWZMj9dl9a+3wV FA0W/D4UUjMb2wk8uREFX2PDpGaCso5/BiSLFpthtaJCAM7CIi81/u6KptmTUtzAttvi nRV6XJfPwQyHMtbQmfSj6dvqK+ZeEtm4LDPXmT83MdIGisfml+/3o7BZShI1+ai3e4ib Zk5sj88JMVzXrLcRjKEwpSrWY3N1lTi5Mo0EyzmvGSDNuYuNrI19cLd+6MvNY4zzM2Cv Bf9Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=Wb4pCdaX; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b=Pmjfga+O; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a62si9260758edf.230.2021.09.13.18.48.39; Mon, 13 Sep 2021 18:49:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=Wb4pCdaX; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b=Pmjfga+O; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242147AbhIMTkl (ORCPT + 99 others); Mon, 13 Sep 2021 15:40:41 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:56418 "EHLO galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242232AbhIMTkh (ORCPT ); Mon, 13 Sep 2021 15:40:37 -0400 Date: Mon, 13 Sep 2021 19:39:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1631561956; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rvh2aNpgEjB+qu7KHhTSh9RhV+DtQghdR7Dqdgn8iro=; b=Wb4pCdaXnoVFQJmX6yFFyGFj0zfx/pPVX5I0WXPQKm9YMz6K0YLirTgSaKFh9bbZWUvbIZ 9kp64vETORNl5TyIHrhZwRaNgp0l//Qu5F3DfBiFlMrsSLj3xWOUNVP5IEOL4BByH0fBsS nP3FAky3MHeQ1Ma/3BYvFkFMX4aIMAD6zuLsC4XcASPFFpH18ZqP7fO/NtgnmiyTN8ccg6 ISx0Vn1zxJkkooCfEUKZLkSM4ka9aGzUvmrFZdTcHUi1DSBYAqH7LMoz51mDEZP7KgQYuY uoiWkrcLgNJWHshOgIyx6RYiGROv3i+ioH7C/oYv2W9EF5wHQFsblBNGKEUmJA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1631561956; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rvh2aNpgEjB+qu7KHhTSh9RhV+DtQghdR7Dqdgn8iro=; b=Pmjfga+ORFACfiuF44o4SvFBmUCIua6xtt3qQLvurCyeevswa1AbdplYw+VfudbGlV+RDO OIYJwHhiYVVbeTBw== From: "tip-bot2 for H. Peter Anvin" Sender: tip-bot2@linutronix.de Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: x86/cpu] x86/asm: Avoid adding register pressure for the init case in static_cpu_has() Cc: "H. Peter Anvin (Intel)" , Borislav Petkov , x86@kernel.org, linux-kernel@vger.kernel.org In-Reply-To: <20210910195910.2542662-4-hpa@zytor.com> References: <20210910195910.2542662-4-hpa@zytor.com> MIME-Version: 1.0 Message-ID: <163156195512.25758.5915554914005716758.tip-bot2@tip-bot2> Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The following commit has been merged into the x86/cpu branch of tip: Commit-ID: 0507503671f9b1c867e889cbec0f43abf904f23c Gitweb: https://git.kernel.org/tip/0507503671f9b1c867e889cbec0f43abf904f23c Author: H. Peter Anvin AuthorDate: Fri, 10 Sep 2021 12:59:10 -07:00 Committer: Borislav Petkov CommitterDate: Mon, 13 Sep 2021 19:48:21 +02:00 x86/asm: Avoid adding register pressure for the init case in static_cpu_has() gcc will sometimes manifest the address of boot_cpu_data in a register as part of constant propagation. When multiple static_cpu_has() are used this may foul the mainline code with a register load which will only be used on the fallback path, which is unused after initialization. Explicitly force gcc to use immediate (rip-relative) addressing for the fallback path, thus removing any possible register use from static_cpu_has(). While making changes, modernize the code to use .pushsection...popsection instead of .section...previous. Signed-off-by: H. Peter Anvin (Intel) Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20210910195910.2542662-4-hpa@zytor.com --- arch/x86/include/asm/cpufeature.h | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h index 16a51e7..1261842 100644 --- a/arch/x86/include/asm/cpufeature.h +++ b/arch/x86/include/asm/cpufeature.h @@ -173,20 +173,25 @@ extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit); * means that the boot_cpu_has() variant is already fast enough for the * majority of cases and you should stick to using it as it is generally * only two instructions: a RIP-relative MOV and a TEST. + * + * Do not use an "m" constraint for [cap_byte] here: gcc doesn't know + * that this is only used on a fallback path and will sometimes cause + * it to manifest the address of boot_cpu_data in a register, fouling + * the mainline (post-initialization) code. */ static __always_inline bool _static_cpu_has(u16 bit) { asm_volatile_goto( ALTERNATIVE_TERNARY("jmp 6f", %P[feature], "", "jmp %l[t_no]") - ".section .altinstr_aux,\"ax\"\n" + ".pushsection .altinstr_aux,\"ax\"\n" "6:\n" - " testb %[bitnum],%[cap_byte]\n" + " testb %[bitnum]," _ASM_RIP(%P[cap_byte]) "\n" " jnz %l[t_yes]\n" " jmp %l[t_no]\n" - ".previous\n" + ".popsection\n" : : [feature] "i" (bit), [bitnum] "i" (1 << (bit & 7)), - [cap_byte] "m" (((const char *)boot_cpu_data.x86_capability)[bit >> 3]) + [cap_byte] "i" (&((const char *)boot_cpu_data.x86_capability)[bit >> 3]) : : t_yes, t_no); t_yes: return true;