Received: by 10.223.176.46 with SMTP id f43csp1126716wra; Sat, 20 Jan 2018 11:27:30 -0800 (PST) X-Google-Smtp-Source: AH8x225R2tlDyc50JbaFhzA3RSV1AjEKY7YAXUwVMnfe4jLeGcnarx19i7EJjG5+V3PP3Vqe7XgR X-Received: by 10.99.94.69 with SMTP id s66mr2725768pgb.155.1516476450491; Sat, 20 Jan 2018 11:27:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516476450; cv=none; d=google.com; s=arc-20160816; b=O8U+9ItSB/VJh820hZyDxM7g6zQdbzQnEML3+FnoJ0c9UoEShlrH2PsjtLflvOnIJo 8giSgVr9a3s4kp9eEDr8VO1mLXdMlGg/+ChD//ZEgp9nWpnAVJG9hG4vxocW++zgOvZZ UTHesBQcGPu3rTF/ZA/33+fCYxSAhE2iDFykbBuNaneXl9gxJ9K6B0GSC5L5ZvYtKVst GE2bWxcpT6GYWf3cTpPr2iYU7EB8FPhqthbcuW0IqNBOjxP7c2Exkby7p6lYwojeJWe0 XcymhzOS4WyTFtrkIg0R4p3KgDR7Jrqmlb37D+mH5WQL1O+wd6qEHKH3i1PNfHcKdMjp 8b7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=AVEkq7KheIPviK2RPlqK/sovkN5xp5l9sCOdscAajnw=; b=V60HcS5RK9XfYaBo0puUz7hFO7pkDoRmRVSHnOPRHDfqE52spNLzQNteENdx8nkaN1 P2R3I1HEhCrfjm+CrnPH76UEoNQgyBKZTt+/Cbw0ZEEhEanaZh0pGhjct1fbnQqO0NiZ kzZ7AVjP/zxHyaD0ioNtO3Iu/irshvnF/cSQjlfQozUMw8+TN6k4OYZC7yHzPJcBOGxM ilb/6hU+osnOaIONtxuRg1QqP5w8vNmGg91OSOVJHjIbR0R7VRr/iJKTsKEUt0gNbJvV QeXMFQ7xb9TPc0SX2v0UW7dMwNh5mHPG9vjuX+UDKXEmbhJholki1dlrjzgNvrcK3qT6 aUXw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amazon.de header.s=amazon201209 header.b=CBYq53eA; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amazon.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z185si10947257pgb.202.2018.01.20.11.27.16; Sat, 20 Jan 2018 11:27:30 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@amazon.de header.s=amazon201209 header.b=CBYq53eA; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amazon.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756550AbeATTZl (ORCPT + 99 others); Sat, 20 Jan 2018 14:25:41 -0500 Received: from smtp-fw-33001.amazon.com ([207.171.190.10]:40622 "EHLO smtp-fw-33001.amazon.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932681AbeATTYB (ORCPT ); Sat, 20 Jan 2018 14:24:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209; t=1516476241; x=1548012241; h=from:to:cc:subject:date:message-id:in-reply-to: references; bh=AVEkq7KheIPviK2RPlqK/sovkN5xp5l9sCOdscAajnw=; b=CBYq53eAkgQIUtL6QAtRRipjVZHNtT67Zo6K3lQmGywKWTLiW/htIW4s nBNEFx5MDx/pK51sJGw8ZK/LAAshWGYarc0VfkB+QGXlB50p6tTCs5NAA Uy/LlAxmunsMptTiZnSa9ZhsELbWHT6Rwyj0v0c3u/K5nmk2OFfKtGqRG A=; X-IronPort-AV: E=Sophos;i="5.46,387,1511827200"; d="scan'208";a="716423200" Received: from sea3-co-svc-lb6-vlan2.sea.amazon.com (HELO email-inbound-relay-1d-9ec21598.us-east-1.amazon.com) ([10.47.22.34]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jan 2018 19:23:58 +0000 Received: from u54e1ad5160425a4b64ea.ant.amazon.com (iad1-ws-svc-lb91-vlan3.amazon.com [10.0.103.150]) by email-inbound-relay-1d-9ec21598.us-east-1.amazon.com (8.14.7/8.14.7) with ESMTP id w0KJNgr5116049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Jan 2018 19:23:44 GMT Received: from u54e1ad5160425a4b64ea.ant.amazon.com (localhost [127.0.0.1]) by u54e1ad5160425a4b64ea.ant.amazon.com (8.15.2/8.15.2/Debian-3) with ESMTP id w0KJNeYX005288; Sat, 20 Jan 2018 20:23:40 +0100 Received: (from karahmed@localhost) by u54e1ad5160425a4b64ea.ant.amazon.com (8.15.2/8.15.2/Submit) id w0KJNdQA005287; Sat, 20 Jan 2018 20:23:39 +0100 From: KarimAllah Ahmed To: linux-kernel@vger.kernel.org Cc: KarimAllah Ahmed , Andi Kleen , Andrea Arcangeli , Andy Lutomirski , Arjan van de Ven , Ashok Raj , Asit Mallick , Borislav Petkov , Dan Williams , Dave Hansen , David Woodhouse , Greg Kroah-Hartman , "H . Peter Anvin" , Ingo Molnar , Janakarajan Natarajan , Joerg Roedel , Jun Nakajima , Laura Abbott , Linus Torvalds , Masami Hiramatsu , Paolo Bonzini , Peter Zijlstra , =?UTF-8?q?Radim=20Kr=C4=8Dm=C3=A1=C5=99?= , Thomas Gleixner , Tim Chen , Tom Lendacky , kvm@vger.kernel.org, x86@kernel.org Subject: [RFC 08/10] x86/idle: Control Indirect Branch Speculation in idle Date: Sat, 20 Jan 2018 20:22:59 +0100 Message-Id: <1516476182-5153-9-git-send-email-karahmed@amazon.de> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1516476182-5153-1-git-send-email-karahmed@amazon.de> References: <1516476182-5153-1-git-send-email-karahmed@amazon.de> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Thomas Gleixner Indirect Branch Speculation (IBS) is controlled per physical core. If one thread disables it then it's disabled for the core. If a thread enters idle it makes sense to reenable IBS so the sibling thread can run with full speculation enabled in user space. This makes only sense in mwait_idle_with_hints() because mwait_idle() can serve an interrupt immediately before speculation can be stopped again. SKL which requires IBRS should use mwait_idle_with_hints() so this is a non issue and in the worst case a missed optimization. Originally-by: Tim Chen Signed-off-by: Thomas Gleixner --- arch/x86/include/asm/mwait.h | 14 ++++++++++++++ arch/x86/kernel/process.c | 14 ++++++++++++++ 2 files changed, 28 insertions(+) diff --git a/arch/x86/include/asm/mwait.h b/arch/x86/include/asm/mwait.h index 39a2fb2..f173072 100644 --- a/arch/x86/include/asm/mwait.h +++ b/arch/x86/include/asm/mwait.h @@ -6,6 +6,7 @@ #include #include +#include #define MWAIT_SUBSTATE_MASK 0xf #define MWAIT_CSTATE_MASK 0xf @@ -106,7 +107,20 @@ static inline void mwait_idle_with_hints(unsigned long eax, unsigned long ecx) mb(); } + /* + * Indirect Branch Speculation (IBS) is controlled per + * physical core. If one thread disables it, then it's + * disabled on all threads of the core. The kernel disables + * it on entry from user space. Reenable it on the thread + * which goes idle so the other thread has a chance to run + * with full speculation enabled in userspace. + */ + unrestrict_branch_speculation(); __monitor((void *)¤t_thread_info()->flags, 0, 0); + /* + * Restrict IBS again to protect kernel execution. + */ + restrict_branch_speculation(); if (!need_resched()) __mwait(eax, ecx); } diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c index 3cb2486..f941c5d 100644 --- a/arch/x86/kernel/process.c +++ b/arch/x86/kernel/process.c @@ -461,6 +461,20 @@ static __cpuidle void mwait_idle(void) mb(); /* quirk */ } + /* + * Indirect Branch Speculation (IBS) is controlled per + * physical core. If one thread disables it, then it's + * disabled on all threads of the core. The kernel disables + * it on entry from user space. For __sti_mwait() it's + * wrong to reenable it because an interrupt can be served + * before speculation can be stopped again. + * + * To plug that hole the interrupt entry code would need to + * save current state and restore. Not worth the trouble as + * SKL should not use mwait_idle(). It should use + * mwait_idle_with_hints() which can do speculation control + * safely. + */ __monitor((void *)¤t_thread_info()->flags, 0, 0); if (!need_resched()) __sti_mwait(0, 0); -- 2.7.4