From patchwork Fri Mar 2 21:42:12 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?b?UmFkaW0gS3LEjW3DocWZ?= X-Patchwork-Id: 10255719 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id A3D7F6037D for ; Fri, 2 Mar 2018 21:43:03 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 93DCF283FE for ; Fri, 2 Mar 2018 21:43:03 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 885C328531; Fri, 2 Mar 2018 21:43:03 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.9 required=2.0 tests=BAYES_00,HK_RANDOM_FROM, RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2F0BB283FE for ; Fri, 2 Mar 2018 21:43:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933995AbeCBVmu (ORCPT ); Fri, 2 Mar 2018 16:42:50 -0500 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:54518 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752432AbeCBVmt (ORCPT ); Fri, 2 Mar 2018 16:42:49 -0500 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DDBD34075168; Fri, 2 Mar 2018 21:42:48 +0000 (UTC) Received: from flask (unknown [10.43.2.80]) by smtp.corp.redhat.com (Postfix) with SMTP id B77A1213AEF8; Fri, 2 Mar 2018 21:42:46 +0000 (UTC) Received: by flask (sSMTP sendmail emulation); Fri, 02 Mar 2018 22:42:12 +0100 Date: Fri, 2 Mar 2018 22:42:12 +0100 From: Radim =?utf-8?B?S3LEjW3DocWZ?= To: Paolo Bonzini Cc: Konrad Rzeszutek Wilk , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, David Woodhouse , KarimAllah Ahmed Subject: Re: [PATCH] KVM: VMX: expose the host's ARCH_CAPABILITIES MSR to userspace Message-ID: <20180302214212.GB13606@flask> References: <1519433546-33879-1-git-send-email-pbonzini@redhat.com> <20180226221300.GK22024@char.us.oracle.com> <20180301213205.GB29001@flask> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Fri, 02 Mar 2018 21:42:48 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Fri, 02 Mar 2018 21:42:48 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'rkrcmar@redhat.com' RCPT:'' Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 2018-03-02 10:36+0100, Paolo Bonzini: > On 01/03/2018 22:39, Radim Krčmář wrote: > > [Resent after removing g@char.us.oracle.com.] > > > > 2018-02-26 17:13-0500, Konrad Rzeszutek Wilk: > >> On Sat, Feb 24, 2018 at 01:52:26AM +0100, Paolo Bonzini wrote: > >>> Use the new MSR feature framework to expose the ARCH_CAPABILITIES MSR to > >>> userspace. This way, userspace can access the capabilities even if it > >>> does not have the permissions to read MSRs. > >> > >> ... That is good but could you expand a bit of why it would want this? > >> > >> I am 99% sure it is due to the lovely spectre_v2 mitigation but > >> could you include that in the commit message so that in say a year > >> folks would know what this is? > > > > Userspace can currently get the MSR by creating a VCPU and reading its > > MSR_IA32_ARCH_CAPABILITIES, because it is set from the hardware MSR. > > > > I thought that "permissions to read MSRs" talked about hardware MSRs, so > > the purpose of this patch would be a better interface, but I don't see > > how if we keep the auto-setting on VCPU creation. > > Yeah, it's mostly about a better interface and being able to do checks > before creating the VCPU. The commit message was written before I > noticed the auto-setting on VCPU creation, and I failed to update it. Ok, sounds good. I've deferred it to rc5 as I think we'll want to use this to replace the auto setting: I would not bet that it is going to be safe to expose future bits, so having the userspace always sanitize the capabilities would be safer (and more in line with what we do with other MSRs). i.e. this patch would also diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index 051dab74e4e9..86ea4a83af1f 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -5740,9 +5740,6 @@ static void vmx_vcpu_setup(struct vcpu_vmx *vmx) ++vmx->nmsrs; } - if (boot_cpu_has(X86_FEATURE_ARCH_CAPABILITIES)) - rdmsrl(MSR_IA32_ARCH_CAPABILITIES, vmx->arch_capabilities); - vm_exit_controls_init(vmx, vmcs_config.vmexit_ctrl); /* 22.2.1, 20.8.1 */