Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934465AbeAJPqP (ORCPT + 1 other); Wed, 10 Jan 2018 10:46:15 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58928 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932166AbeAJPqN (ORCPT ); Wed, 10 Jan 2018 10:46:13 -0500 Subject: Re: [PATCH 3/8] kvm: vmx: pass MSR_IA32_SPEC_CTRL and MSR_IA32_PRED_CMD down to the guest To: Konrad Rzeszutek Wilk Cc: Arjan van de Ven , Nadav Amit , Liran Alon , jmattson@google.com, x86@kernel.org, dwmw@amazon.co.uk, bp@alien8.de, aliguori@amazon.com, thomas.lendacky@amd.com, rkrcmar@redhat.com, linux-kernel@vger.kernel.org, kvm@vger.kernel.org References: <222d0a6b-820f-4d7c-a616-ac89f77c3c09@default> <834e9b46-5d59-a81e-8cda-5f576964e1cb@redhat.com> <9360a280-228d-26d9-5561-6688aa67881c@linux.intel.com> <91d41f66-d744-e8b0-89f0-a167d3a3918c@redhat.com> <20180110154138.GE29272@char.us.oracle.com> From: Paolo Bonzini Message-ID: Date: Wed, 10 Jan 2018 16:45:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20180110154138.GE29272@char.us.oracle.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Wed, 10 Jan 2018 15:46:13 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On 10/01/2018 16:41, Konrad Rzeszutek Wilk wrote: > On Wed, Jan 10, 2018 at 03:28:43PM +0100, Paolo Bonzini wrote: >> On 10/01/2018 15:06, Arjan van de Ven wrote: >>> On 1/10/2018 5:20 AM, Paolo Bonzini wrote: >>>> * a simple specification that does "IBRS=1 blocks indirect branch >>>> prediction altogether" would actually satisfy the specification just as >>>> well, and it would be nice to know if that's what the processor actually >>>> does. >>> >>> it doesn't exactly, not for all. >>> >>> so you really do need to write ibrs again. >> >> Okay, so "always set IBRS=1" does *not* protect against variant 2. Thanks, > > And what is the point of this "always set IBRS=1" then? Are there some other > things lurking in the shadows? The idea was that: 1) for workloads that are very kernel-heavy "always set IBRS=1" would be faster than flipping it on kernel entry/exit, 2) skipping the IBRS=1 write on vmexit would be a nice optimization because most vmexits come from guest ring 0. But apparently it's a non-starter. :( Paolo