From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x227foQi2LlayYnM2A9iCbw+DwYErIcEVV+2gq2oivxlx7Ap6GnERusy2j6QwHUnKlCDWprFY ARC-Seal: i=1; a=rsa-sha256; t=1516749764; cv=none; d=google.com; s=arc-20160816; b=RfQJFgsUHZtJwY0WthBGwBQnkiw2Ufns42S68Um5lT7X78r0J3zps/baStVQaFPk3S AXBtLXNrEkj60DRiokZ2XDtSDmHBsKZPGq+Gc7xUa+6bY5jQkf8nDaZD7EZShYzXthwA AbARjqVZ8wSGSucCOacncgoKLka2/+pkvcWmWJd5hnE4ggFm0jAYgfWq2M3r3lQcw9Cv lgWKjblOGPT3TiCGM5/ULTJv0EKg7o+BvKdMeu6n8ePR25Z2L8VTbbkEM97VAPqbvs0Q WCi9gV125wgtVdKPnf7btIcighA0ACTK0r+Ph3Zc5TRXFUu862DKxRMnt195VtQpF81d wo4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=JZDJhEA/8Z22/qFyN55dZJ9mqT/vIGA0jDzmKH5b+L0=; b=WQggiW73ROYZUuKaUjaENn8ymEWqtMUm+RiyvvgNmCYKb2Frhf6Ey1pxIOG/iOwxTC fbQ14MDvNKtgEegc2Lk3Euv675IOee8CvPtoNJJ4SDauFVKgwF32VTT7O3SL1GtI2UsW lpYeBb8P/xzEw4vXx57tOtK8dIsKzJd+MA7xpwYKmAHuvng6N6xj9xoGQ7qu+50/hUvH gYf5pbEaOZCaZNEQsLIpw00RA78tP8jramLRC8hW5IOOGFEjtA4u+/g5Nu1gm2r2Xxpa sk5QRBypPUldK1BKGFUF/9xBHUZ7Cn0jqJWN/x7JvDIzCWU9Uwt6qkFyZ/Fe7yWZbWm4 ArVQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of ak@linux.intel.com designates 134.134.136.24 as permitted sender) smtp.mailfrom=ak@linux.intel.com Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of ak@linux.intel.com designates 134.134.136.24 as permitted sender) smtp.mailfrom=ak@linux.intel.com X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,403,1511856000"; d="scan'208";a="168610997" Date: Tue, 23 Jan 2018 15:22:35 -0800 From: Andi Kleen To: "Woodhouse, David" Cc: "thomas.lendacky@amd.com" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "peterz@infradead.org" , "ashok.raj@intel.com" , "Raslan, KarimAllah" , "arjan.van.de.ven@intel.com" , "arjan@linux.intel.com" , "bp@suse.de" , "tglx@linutronix.de" , "Janakarajan.Natarajan@amd.com" , "tim.c.chen@linux.intel.com" , "torvalds@linux-foundation.org" , "joro@8bytes.org" , "dan.j.williams@intel.com" , "x86@kernel.org" , "hpa@zytor.com" , "aarcange@redhat.com" , "mingo@redhat.com" , "luto@kernel.org" , "pbonzini@redhat.com" , "gregkh@linuxfoundation.org" , "dave.hansen@intel.com" , "luto@amacapital.net" , "mhiramat@kernel.org" , "asit.k.mallick@intel.com" , "jun.nakajima@intel.com" , "labbott@redhat.com" , "rkrcmar@redhat.com" Subject: Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation Message-ID: <20180123232235.GT7844@tassilo.jf.intel.com> References: <1516476182-5153-1-git-send-email-karahmed@amazon.de> <1516476182-5153-10-git-send-email-karahmed@amazon.de> <243BE571-AF73-44B3-8D17-193F9E07686A@amacapital.net> <4e01a7a9-29e4-adcc-3f53-550fb7f3d370@amd.com> <1516724457.9521.156.camel@amazon.co.uk> <20180123224956.GQ7844@tassilo.jf.intel.com> <1516749276.13558.25.camel@amazon.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1516749276.13558.25.camel@amazon.co.uk> User-Agent: Mutt/1.9.1 (2017-09-22) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590140582166248265?= X-GMAIL-MSGID: =?utf-8?q?1590427401568229445?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Tue, Jan 23, 2018 at 11:14:36PM +0000, Woodhouse, David wrote: > On Tue, 2018-01-23 at 14:49 -0800, Andi Kleen wrote: > > > Not sure.  Maybe to start, the answer might be to allow it to be set for > > > the ultra-paranoid, but in general don't enable it by default.  Having it > > > enabled would be an alternative to someone deciding to disable SMT, since > > > that would have even more of a performance impact. > > > > I agree. A reasonable strategy would be to only enable it for > > processes that have dumpable disabled. This should be already set for > > high value processes like GPG, and allows others to opt-in if > > they need to. > > That seems to make sense, and I think was the solution we were > approaching for IBPB on context switch too, right? Right. -Andi