Message ID | 20231108183003.5981-6-xin3.li@intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:aa0b:0:b0:403:3b70:6f57 with SMTP id k11csp1125337vqo; Wed, 8 Nov 2023 11:04:18 -0800 (PST) X-Google-Smtp-Source: AGHT+IH2u64DBt8SWBuHAMTRMf1RvsMWuUVXWEU9o3kaTxxYrT4Cz7Z5QTe/xU0YzEDpfbLu1reG X-Received: by 2002:a17:902:e809:b0:1cc:6d2c:fb59 with SMTP id u9-20020a170902e80900b001cc6d2cfb59mr3340815plg.28.1699470258108; Wed, 08 Nov 2023 11:04:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1699470258; cv=none; d=google.com; s=arc-20160816; b=ARtJ+DZTN0nAp+8hJMknlhWE1n8Lu2lUWmibKUlofgOiyyLCP6Q62TMjOcWQyfF+QD svl808RAKPzqvQf95WPRd2k3p22rR7Bg7f2hZA+cX33cfXFs05BrdSA94krVVIgLpoz2 /iQeliy98+lbJ+WUfj4nttQYtppxUEU/armfGwqQtprembXrJIaCiYjyDHNWjEIV1rum fwojRKMnCOWz5Tqr/NDF9l2758DXk1O4OXoI89+305tuMlnpUadGyeaxO37ofBS//A3f XwddHWkw01s7xEYIbF3B+YPb5WpITQ0QT1Fo4xZLQsh4du/yYKXqS+j1Be6pAM5aSiyK hZPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=sEJ7/sp3XXLC84YVSmuLal7scRXrtb2j3SEHx7k4G14=; fh=jyCs2STAghiemYCMqutk2CMon3BCEX6sSSqaVLqDaaU=; b=M5f/7wV/ScrApVHVabnbjt6BxnsU+GZwuvnv4wwh6W1UNbbjwfT9HfS6gWIMM+vmiY 9lyPGCkx1xjDMd+VDWSvvsul9hk0uD0q6hx77NQ5GA53KyMRXLyUtoTOIE9kKVa4d8Yp qz35VGTB+cudn5WFryP58h39wsR9Z7dbUpSGgalFUxZ2RQBRX2n7kcwjojjfol5A0BDT Kg1C8P2lELDbQbA0Ac6RmC49ch++mNHsGuy9OnoT99Hk1qHn3588wZHzo46Jda8h/0e/ qaGxgJVJS7G8ZDXFB7q0gaQTHexdLVxXMZR78MhZ2+MMeIY0TIEQI3xFHfiSHJ84+rGJ D8XA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=daAhlHBx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id y13-20020a17090322cd00b001cc2ef72ab2si3123921plg.68.2023.11.08.11.04.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Nov 2023 11:04:18 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=daAhlHBx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id F1DCD813389D; Wed, 8 Nov 2023 11:00:43 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232727AbjKHTAa (ORCPT <rfc822;jaysivo@gmail.com> + 32 others); Wed, 8 Nov 2023 14:00:30 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53188 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231881AbjKHTAV (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 8 Nov 2023 14:00:21 -0500 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.9]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 87EF62114; Wed, 8 Nov 2023 11:00:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1699470020; x=1731006020; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=LsNdQwHiUrqX8YGCdaIq6LWa12llh8k5EG8vDmKHiu8=; b=daAhlHBxchoiTN8bjik8yPpdqIhe8fREln3IrJxPdS3X1zhctcYywsN0 k130ZolIxhm/fAXfSlILBSl5bjHGX1z0K9famlaDxwqnIiZ7TOFLVjM09 1hJK56xAJztRN6gcLPYJl5+IAF2/hBSXMaGKBb7EpWmxwvILAVfjdIVKX UWDgwaTBHPV87KPFiRhq88eubxjD/sn1DJEir8nIQMaQs9Rok/wOtCE0b i+0UsKSfgQjsZWx2X3DFIvtf+TZ2j2PjClNho4loRDaDP3UnHD7sJitte Rea3pJPISpGODW+ObIGRgam18dogG8eeXiaruqoHXTF+iMWwzylLnM12U Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10888"; a="8486254" X-IronPort-AV: E=Sophos;i="6.03,287,1694761200"; d="scan'208";a="8486254" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Nov 2023 11:00:19 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.03,287,1694761200"; d="scan'208";a="10892428" Received: from unknown (HELO fred..) ([172.25.112.68]) by orviesa001.jf.intel.com with ESMTP; 08 Nov 2023 11:00:18 -0800 From: Xin Li <xin3.li@intel.com> To: kvm@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org, linux-kselftest@vger.kernel.org Cc: seanjc@google.com, pbonzini@redhat.com, corbet@lwn.net, kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, vkuznets@redhat.com, peterz@infradead.org, ravi.v.shankar@intel.com Subject: [PATCH v1 05/23] KVM: VMX: Initialize FRED VM entry/exit controls in vmcs_config Date: Wed, 8 Nov 2023 10:29:45 -0800 Message-ID: <20231108183003.5981-6-xin3.li@intel.com> X-Mailer: git-send-email 2.42.0 In-Reply-To: <20231108183003.5981-1-xin3.li@intel.com> References: <20231108183003.5981-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Wed, 08 Nov 2023 11:00:44 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1782023725251452285 X-GMAIL-MSGID: 1782023725251452285 |
Series |
Enable FRED with KVM VMX
|
|
Commit Message
Li, Xin3
Nov. 8, 2023, 6:29 p.m. UTC
Setup the global vmcs_config for FRED: 1) Add VM_ENTRY_LOAD_IA32_FRED to KVM_OPTIONAL_VMX_VM_ENTRY_CONTROLS to have a FRED CPU load guest FRED MSRs from VMCS upon VM entry. 2) Add SECONDARY_VM_EXIT_SAVE_IA32_FRED to KVM_OPTIONAL_VMX_SECONDARY_VM_EXIT_CONTROLS to have a FRED CPU save guest FRED MSRs to VMCS during VM exit. 3) add SECONDARY_VM_EXIT_LOAD_IA32_FRED to KVM_OPTIONAL_VMX_SECONDARY_VM_EXIT_CONTROLS to have a FRED CPU load host FRED MSRs from VMCS during VM exit. Also add sanity checks to make sure FRED VM entry/exit controls can be set on a FRED CPU. Tested-by: Shan Kang <shan.kang@intel.com> Signed-off-by: Xin Li <xin3.li@intel.com> --- arch/x86/include/asm/vmx.h | 3 +++ arch/x86/kvm/vmx/vmx.c | 19 ++++++++++++++++++- arch/x86/kvm/vmx/vmx.h | 7 +++++-- 3 files changed, 26 insertions(+), 3 deletions(-)
Comments
On Wed, Nov 08, 2023 at 10:29:45AM -0800, Xin Li wrote: >Setup the global vmcs_config for FRED: >1) Add VM_ENTRY_LOAD_IA32_FRED to KVM_OPTIONAL_VMX_VM_ENTRY_CONTROLS to > have a FRED CPU load guest FRED MSRs from VMCS upon VM entry. >2) Add SECONDARY_VM_EXIT_SAVE_IA32_FRED to > KVM_OPTIONAL_VMX_SECONDARY_VM_EXIT_CONTROLS to have a FRED CPU save > guest FRED MSRs to VMCS during VM exit. >3) add SECONDARY_VM_EXIT_LOAD_IA32_FRED to > KVM_OPTIONAL_VMX_SECONDARY_VM_EXIT_CONTROLS to have a FRED CPU load > host FRED MSRs from VMCS during VM exit. > >Also add sanity checks to make sure FRED VM entry/exit controls can be >set on a FRED CPU. > >Tested-by: Shan Kang <shan.kang@intel.com> >Signed-off-by: Xin Li <xin3.li@intel.com> >--- > arch/x86/include/asm/vmx.h | 3 +++ > arch/x86/kvm/vmx/vmx.c | 19 ++++++++++++++++++- > arch/x86/kvm/vmx/vmx.h | 7 +++++-- > 3 files changed, 26 insertions(+), 3 deletions(-) > >diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h >index 4d4177ec802c..41796a733bc9 100644 >--- a/arch/x86/include/asm/vmx.h >+++ b/arch/x86/include/asm/vmx.h >@@ -106,6 +106,8 @@ > #define VM_EXIT_PT_CONCEAL_PIP 0x01000000 > #define VM_EXIT_CLEAR_IA32_RTIT_CTL 0x02000000 > #define VM_EXIT_ACTIVATE_SECONDARY_CONTROLS 0x80000000 >+#define SECONDARY_VM_EXIT_SAVE_IA32_FRED 0x00000001 >+#define SECONDARY_VM_EXIT_LOAD_IA32_FRED 0x00000002 > > #define VM_EXIT_ALWAYSON_WITHOUT_TRUE_MSR 0x00036dff > >@@ -119,6 +121,7 @@ > #define VM_ENTRY_LOAD_BNDCFGS 0x00010000 > #define VM_ENTRY_PT_CONCEAL_PIP 0x00020000 > #define VM_ENTRY_LOAD_IA32_RTIT_CTL 0x00040000 >+#define VM_ENTRY_LOAD_IA32_FRED 0x00800000 > > #define VM_ENTRY_ALWAYSON_WITHOUT_TRUE_MSR 0x000011ff > >diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c >index df769207cbe0..9186f41974ab 100644 >--- a/arch/x86/kvm/vmx/vmx.c >+++ b/arch/x86/kvm/vmx/vmx.c >@@ -2694,10 +2694,27 @@ static int setup_vmcs_config(struct vmcs_config *vmcs_conf, > _vmexit_control &= ~x_ctrl; > } > >- if (_vmexit_control & VM_EXIT_ACTIVATE_SECONDARY_CONTROLS) >+ if (_vmexit_control & VM_EXIT_ACTIVATE_SECONDARY_CONTROLS) { > _secondary_vmexit_control = > adjust_vmx_controls64(KVM_OPTIONAL_VMX_SECONDARY_VM_EXIT_CONTROLS, > MSR_IA32_VMX_EXIT_CTLS2); >+ if (cpu_feature_enabled(X86_FEATURE_FRED) && >+ !(_secondary_vmexit_control & SECONDARY_VM_EXIT_SAVE_IA32_FRED && >+ _secondary_vmexit_control & SECONDARY_VM_EXIT_LOAD_IA32_FRED)) { >+ pr_warn_once("FRED enabled but no VMX VM-Exit {SAVE,LOAD}_IA32_FRED controls: %llx\n", >+ _secondary_vmexit_control); if there is no VM_EXIT_ACTIVATE_SECONDARY_CONTROLS, shouldn't we also emit this warning? >+ if (error_on_inconsistent_vmcs_config) >+ return -EIO; >+ } >+ } >+ >+ if (cpu_feature_enabled(X86_FEATURE_FRED) && >+ !(_vmentry_control & VM_ENTRY_LOAD_IA32_FRED)) { >+ pr_warn_once("FRED enabled but no VMX VM-Entry LOAD_IA32_FRED control: %x\n", >+ _vmentry_control); Can we just hide FRED from guests like what KVM does for other features which have similar dependencies? see vmx_set_cpu_caps().
On Thu, Nov 09, 2023, Chao Gao wrote: > On Wed, Nov 08, 2023 at 10:29:45AM -0800, Xin Li wrote: > >Setup the global vmcs_config for FRED: > >1) Add VM_ENTRY_LOAD_IA32_FRED to KVM_OPTIONAL_VMX_VM_ENTRY_CONTROLS to > > have a FRED CPU load guest FRED MSRs from VMCS upon VM entry. > >2) Add SECONDARY_VM_EXIT_SAVE_IA32_FRED to > > KVM_OPTIONAL_VMX_SECONDARY_VM_EXIT_CONTROLS to have a FRED CPU save > > guest FRED MSRs to VMCS during VM exit. > >3) add SECONDARY_VM_EXIT_LOAD_IA32_FRED to > > KVM_OPTIONAL_VMX_SECONDARY_VM_EXIT_CONTROLS to have a FRED CPU load > > host FRED MSRs from VMCS during VM exit. > > > >Also add sanity checks to make sure FRED VM entry/exit controls can be > >set on a FRED CPU. > > > >Tested-by: Shan Kang <shan.kang@intel.com> > >Signed-off-by: Xin Li <xin3.li@intel.com> > >--- > > arch/x86/include/asm/vmx.h | 3 +++ > > arch/x86/kvm/vmx/vmx.c | 19 ++++++++++++++++++- > > arch/x86/kvm/vmx/vmx.h | 7 +++++-- > > 3 files changed, 26 insertions(+), 3 deletions(-) > > > >diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h > >index 4d4177ec802c..41796a733bc9 100644 > >--- a/arch/x86/include/asm/vmx.h > >+++ b/arch/x86/include/asm/vmx.h > >@@ -106,6 +106,8 @@ > > #define VM_EXIT_PT_CONCEAL_PIP 0x01000000 > > #define VM_EXIT_CLEAR_IA32_RTIT_CTL 0x02000000 > > #define VM_EXIT_ACTIVATE_SECONDARY_CONTROLS 0x80000000 > >+#define SECONDARY_VM_EXIT_SAVE_IA32_FRED 0x00000001 > >+#define SECONDARY_VM_EXIT_LOAD_IA32_FRED 0x00000002 > > > > #define VM_EXIT_ALWAYSON_WITHOUT_TRUE_MSR 0x00036dff > > > >@@ -119,6 +121,7 @@ > > #define VM_ENTRY_LOAD_BNDCFGS 0x00010000 > > #define VM_ENTRY_PT_CONCEAL_PIP 0x00020000 > > #define VM_ENTRY_LOAD_IA32_RTIT_CTL 0x00040000 > >+#define VM_ENTRY_LOAD_IA32_FRED 0x00800000 > > > > #define VM_ENTRY_ALWAYSON_WITHOUT_TRUE_MSR 0x000011ff > > > >diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c > >index df769207cbe0..9186f41974ab 100644 > >--- a/arch/x86/kvm/vmx/vmx.c > >+++ b/arch/x86/kvm/vmx/vmx.c > >@@ -2694,10 +2694,27 @@ static int setup_vmcs_config(struct vmcs_config *vmcs_conf, > > _vmexit_control &= ~x_ctrl; > > } > > > >- if (_vmexit_control & VM_EXIT_ACTIVATE_SECONDARY_CONTROLS) > >+ if (_vmexit_control & VM_EXIT_ACTIVATE_SECONDARY_CONTROLS) { > > _secondary_vmexit_control = > > adjust_vmx_controls64(KVM_OPTIONAL_VMX_SECONDARY_VM_EXIT_CONTROLS, > > MSR_IA32_VMX_EXIT_CTLS2); > >+ if (cpu_feature_enabled(X86_FEATURE_FRED) && > >+ !(_secondary_vmexit_control & SECONDARY_VM_EXIT_SAVE_IA32_FRED && > >+ _secondary_vmexit_control & SECONDARY_VM_EXIT_LOAD_IA32_FRED)) { > >+ pr_warn_once("FRED enabled but no VMX VM-Exit {SAVE,LOAD}_IA32_FRED controls: %llx\n", > >+ _secondary_vmexit_control); > > if there is no VM_EXIT_ACTIVATE_SECONDARY_CONTROLS, shouldn't we also emit this > warning? > > >+ if (error_on_inconsistent_vmcs_config) > >+ return -EIO; > >+ } > >+ } > >+ > >+ if (cpu_feature_enabled(X86_FEATURE_FRED) && > >+ !(_vmentry_control & VM_ENTRY_LOAD_IA32_FRED)) { > >+ pr_warn_once("FRED enabled but no VMX VM-Entry LOAD_IA32_FRED control: %x\n", > >+ _vmentry_control); > > Can we just hide FRED from guests like what KVM does for other features which > have similar dependencies? see vmx_set_cpu_caps(). Both of these warnings should simply be dropped. The error_on_inconsistent_vmcs_config stuff is for inconsistencies within the allowed VMCS fields. Having a feature that is supported in bare metal but not virtualized is perfectly legal, if uncommon. What *is* needed is for KVM to refuse to virtualize FRED if the entry/exit controls aren't consistent. E.g. if at least one control is present, and at least one control is missing. I.e. KVM needs a version of vmcs_entry_exit_pairs that can deal with SECONDAY_VM_EXIT controls. I'll circle back to this when I give the series a proper review, which is going to be 3+ weeks.
> > >+ if (cpu_feature_enabled(X86_FEATURE_FRED) && > > >+ !(_vmentry_control & VM_ENTRY_LOAD_IA32_FRED)) { > > >+ pr_warn_once("FRED enabled but no VMX VM-Entry > LOAD_IA32_FRED control: %x\n", > > >+ _vmentry_control); > > > > Can we just hide FRED from guests like what KVM does for other > > features which have similar dependencies? see vmx_set_cpu_caps(). > > Both of these warnings should simply be dropped. The > error_on_inconsistent_vmcs_config stuff is for inconsistencies within the allowed > VMCS fields. Having a feature that is supported in bare metal but not virtualized > is perfectly legal, if uncommon. I deliberately keep it, at least for now, because these checks are helpful during the development of nVMX FRED. It will be helpful for other VMMs being developed/tested on KVM. > What *is* needed is for KVM to refuse to virtualize FRED if the entry/exit controls > aren't consistent. E.g. if at least one control is present, and at least one > control is missing. I.e. KVM needs a version of vmcs_entry_exit_pairs that can > deal with SECONDAY_VM_EXIT controls. I agree there are better ways. But maybe after or before VMX FRED. > I'll circle back to this when I give the > series a proper review, which is going to be 3+ weeks. The traffic in KVM mailing list is surprisingly high recently. So that is totally expected.
On Fri, Nov 10, 2023, Xin3 Li wrote: > > > >+ if (cpu_feature_enabled(X86_FEATURE_FRED) && > > > >+ !(_vmentry_control & VM_ENTRY_LOAD_IA32_FRED)) { > > > >+ pr_warn_once("FRED enabled but no VMX VM-Entry > > LOAD_IA32_FRED control: %x\n", > > > >+ _vmentry_control); > > > > > > Can we just hide FRED from guests like what KVM does for other > > > features which have similar dependencies? see vmx_set_cpu_caps(). > > > > Both of these warnings should simply be dropped. The > > error_on_inconsistent_vmcs_config stuff is for inconsistencies within the allowed > > VMCS fields. Having a feature that is supported in bare metal but not virtualized > > is perfectly legal, if uncommon. > > I deliberately keep it, at least for now, because these checks are helpful > during the development of nVMX FRED. It will be helpful for other VMMs > being developed/tested on KVM. No, remove it. It's architecturally legal for a CPU to support a feature in bare metal but not provide virtualization support. > > What *is* needed is for KVM to refuse to virtualize FRED if the entry/exit controls > > aren't consistent. E.g. if at least one control is present, and at least one > > control is missing. I.e. KVM needs a version of vmcs_entry_exit_pairs that can > > deal with SECONDAY_VM_EXIT controls. > > I agree there are better ways. But maybe after or before VMX FRED. Uh, no. This is not optional. FRED is the first feature that uses SECONDAY_VM_EXIT controls, so FRED gets the honor of adding the necessary infrastructure support.
On 8.11.23 г. 20:29 ч., Xin Li wrote: > Setup the global vmcs_config for FRED: > 1) Add VM_ENTRY_LOAD_IA32_FRED to KVM_OPTIONAL_VMX_VM_ENTRY_CONTROLS to > have a FRED CPU load guest FRED MSRs from VMCS upon VM entry. > 2) Add SECONDARY_VM_EXIT_SAVE_IA32_FRED to > KVM_OPTIONAL_VMX_SECONDARY_VM_EXIT_CONTROLS to have a FRED CPU save > guest FRED MSRs to VMCS during VM exit. > 3) add SECONDARY_VM_EXIT_LOAD_IA32_FRED to > KVM_OPTIONAL_VMX_SECONDARY_VM_EXIT_CONTROLS to have a FRED CPU load > host FRED MSRs from VMCS during VM exit. > > Also add sanity checks to make sure FRED VM entry/exit controls can be > set on a FRED CPU. > > Tested-by: Shan Kang <shan.kang@intel.com> > Signed-off-by: Xin Li <xin3.li@intel.com> > --- > arch/x86/include/asm/vmx.h | 3 +++ > arch/x86/kvm/vmx/vmx.c | 19 ++++++++++++++++++- > arch/x86/kvm/vmx/vmx.h | 7 +++++-- > 3 files changed, 26 insertions(+), 3 deletions(-) > > diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h > index 4d4177ec802c..41796a733bc9 100644 > --- a/arch/x86/include/asm/vmx.h > +++ b/arch/x86/include/asm/vmx.h > @@ -106,6 +106,8 @@ > #define VM_EXIT_PT_CONCEAL_PIP 0x01000000 > #define VM_EXIT_CLEAR_IA32_RTIT_CTL 0x02000000 > #define VM_EXIT_ACTIVATE_SECONDARY_CONTROLS 0x80000000 > +#define SECONDARY_VM_EXIT_SAVE_IA32_FRED 0x00000001 > +#define SECONDARY_VM_EXIT_LOAD_IA32_FRED 0x00000002 > > #define VM_EXIT_ALWAYSON_WITHOUT_TRUE_MSR 0x00036dff > > @@ -119,6 +121,7 @@ > #define VM_ENTRY_LOAD_BNDCFGS 0x00010000 > #define VM_ENTRY_PT_CONCEAL_PIP 0x00020000 > #define VM_ENTRY_LOAD_IA32_RTIT_CTL 0x00040000 > +#define VM_ENTRY_LOAD_IA32_FRED 0x00800000 > > #define VM_ENTRY_ALWAYSON_WITHOUT_TRUE_MSR 0x000011ff > > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c > index df769207cbe0..9186f41974ab 100644 > --- a/arch/x86/kvm/vmx/vmx.c > +++ b/arch/x86/kvm/vmx/vmx.c > @@ -2694,10 +2694,27 @@ static int setup_vmcs_config(struct vmcs_config *vmcs_conf, > _vmexit_control &= ~x_ctrl; > } > > - if (_vmexit_control & VM_EXIT_ACTIVATE_SECONDARY_CONTROLS) > + if (_vmexit_control & VM_EXIT_ACTIVATE_SECONDARY_CONTROLS) { > _secondary_vmexit_control = > adjust_vmx_controls64(KVM_OPTIONAL_VMX_SECONDARY_VM_EXIT_CONTROLS, > MSR_IA32_VMX_EXIT_CTLS2); > + if (cpu_feature_enabled(X86_FEATURE_FRED) && > + !(_secondary_vmexit_control & SECONDARY_VM_EXIT_SAVE_IA32_FRED && > + _secondary_vmexit_control & SECONDARY_VM_EXIT_LOAD_IA32_FRED)) { Can those checks actually trigger? I.e if FEATURE_FRED is set it means the CPU implements the FRED spec. According to the spec it's guaranteed that VMX_EXIT_CTLS2 will contain those bits set to 1. So aren't those checks superfluous? > + pr_warn_once("FRED enabled but no VMX VM-Exit {SAVE,LOAD}_IA32_FRED controls: %llx\n", > + _secondary_vmexit_control); > + if (error_on_inconsistent_vmcs_config) > + return -EIO; > + } > + } > + > + if (cpu_feature_enabled(X86_FEATURE_FRED) && > + !(_vmentry_control & VM_ENTRY_LOAD_IA32_FRED)) { DITTO <snip>
> > > > Can we just hide FRED from guests like what KVM does for other > > > > features which have similar dependencies? see vmx_set_cpu_caps(). > > > > > > Both of these warnings should simply be dropped. The > > > error_on_inconsistent_vmcs_config stuff is for inconsistencies within the > allowed > > > VMCS fields. Having a feature that is supported in bare metal but not > virtualized > > > is perfectly legal, if uncommon. > > > > I deliberately keep it, at least for now, because these checks are helpful > > during the development of nVMX FRED. It will be helpful for other VMMs > > being developed/tested on KVM. > > No, remove it. It's architecturally legal for a CPU to support a feature in bare > metal but not provide virtualization support. Like the stage when native Linux has FRED support while KVM not yet? > > > What *is* needed is for KVM to refuse to virtualize FRED if the entry/exit > controls > > > aren't consistent. E.g. if at least one control is present, and at least one > > > control is missing. I.e. KVM needs a version of vmcs_entry_exit_pairs that can > > > deal with SECONDAY_VM_EXIT controls. > > > > I agree there are better ways. But maybe after or before VMX FRED. > > Uh, no. This is not optional. FRED is the first feature that uses > SECONDAY_VM_EXIT > controls, so FRED gets the honor of adding the necessary infrastructure support. The 2nd VM exit controls is a must for FRED, so I should do it. I think you mean the consistency checks can be done in a better way (which is not just for FRED controls consistency checks). No? Thanks! Xin
> > - if (_vmexit_control & VM_EXIT_ACTIVATE_SECONDARY_CONTROLS) > > + if (_vmexit_control & VM_EXIT_ACTIVATE_SECONDARY_CONTROLS) { > > _secondary_vmexit_control = > > > adjust_vmx_controls64(KVM_OPTIONAL_VMX_SECONDARY_VM_EXIT_CO > NTROLS, > > MSR_IA32_VMX_EXIT_CTLS2); > > + if (cpu_feature_enabled(X86_FEATURE_FRED) && > > + !(_secondary_vmexit_control & > SECONDARY_VM_EXIT_SAVE_IA32_FRED && > > + _secondary_vmexit_control & > SECONDARY_VM_EXIT_LOAD_IA32_FRED)) { > > Can those checks actually trigger? I.e if FEATURE_FRED is set it means > the CPU implements the FRED spec. According to the spec it's guaranteed > that VMX_EXIT_CTLS2 will contain those bits set to 1. So aren't those > checks superfluous? Such checks are for nVMX FRED. > > + if (cpu_feature_enabled(X86_FEATURE_FRED) && > > + !(_vmentry_control & VM_ENTRY_LOAD_IA32_FRED)) { > DITTO > > <snip>
diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h index 4d4177ec802c..41796a733bc9 100644 --- a/arch/x86/include/asm/vmx.h +++ b/arch/x86/include/asm/vmx.h @@ -106,6 +106,8 @@ #define VM_EXIT_PT_CONCEAL_PIP 0x01000000 #define VM_EXIT_CLEAR_IA32_RTIT_CTL 0x02000000 #define VM_EXIT_ACTIVATE_SECONDARY_CONTROLS 0x80000000 +#define SECONDARY_VM_EXIT_SAVE_IA32_FRED 0x00000001 +#define SECONDARY_VM_EXIT_LOAD_IA32_FRED 0x00000002 #define VM_EXIT_ALWAYSON_WITHOUT_TRUE_MSR 0x00036dff @@ -119,6 +121,7 @@ #define VM_ENTRY_LOAD_BNDCFGS 0x00010000 #define VM_ENTRY_PT_CONCEAL_PIP 0x00020000 #define VM_ENTRY_LOAD_IA32_RTIT_CTL 0x00040000 +#define VM_ENTRY_LOAD_IA32_FRED 0x00800000 #define VM_ENTRY_ALWAYSON_WITHOUT_TRUE_MSR 0x000011ff diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index df769207cbe0..9186f41974ab 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -2694,10 +2694,27 @@ static int setup_vmcs_config(struct vmcs_config *vmcs_conf, _vmexit_control &= ~x_ctrl; } - if (_vmexit_control & VM_EXIT_ACTIVATE_SECONDARY_CONTROLS) + if (_vmexit_control & VM_EXIT_ACTIVATE_SECONDARY_CONTROLS) { _secondary_vmexit_control = adjust_vmx_controls64(KVM_OPTIONAL_VMX_SECONDARY_VM_EXIT_CONTROLS, MSR_IA32_VMX_EXIT_CTLS2); + if (cpu_feature_enabled(X86_FEATURE_FRED) && + !(_secondary_vmexit_control & SECONDARY_VM_EXIT_SAVE_IA32_FRED && + _secondary_vmexit_control & SECONDARY_VM_EXIT_LOAD_IA32_FRED)) { + pr_warn_once("FRED enabled but no VMX VM-Exit {SAVE,LOAD}_IA32_FRED controls: %llx\n", + _secondary_vmexit_control); + if (error_on_inconsistent_vmcs_config) + return -EIO; + } + } + + if (cpu_feature_enabled(X86_FEATURE_FRED) && + !(_vmentry_control & VM_ENTRY_LOAD_IA32_FRED)) { + pr_warn_once("FRED enabled but no VMX VM-Entry LOAD_IA32_FRED control: %x\n", + _vmentry_control); + if (error_on_inconsistent_vmcs_config) + return -EIO; + } rdmsrl(MSR_IA32_VMX_BASIC, basic_msr); diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h index 99a0f6783085..f8c02bd37069 100644 --- a/arch/x86/kvm/vmx/vmx.h +++ b/arch/x86/kvm/vmx/vmx.h @@ -480,7 +480,8 @@ static inline u8 vmx_get_rvi(void) VM_ENTRY_LOAD_IA32_EFER | \ VM_ENTRY_LOAD_BNDCFGS | \ VM_ENTRY_PT_CONCEAL_PIP | \ - VM_ENTRY_LOAD_IA32_RTIT_CTL) + VM_ENTRY_LOAD_IA32_RTIT_CTL | \ + VM_ENTRY_LOAD_IA32_FRED) #define __KVM_REQUIRED_VMX_VM_EXIT_CONTROLS \ (VM_EXIT_SAVE_DEBUG_CONTROLS | \ @@ -506,7 +507,9 @@ static inline u8 vmx_get_rvi(void) VM_EXIT_ACTIVATE_SECONDARY_CONTROLS) #define KVM_REQUIRED_VMX_SECONDARY_VM_EXIT_CONTROLS (0) -#define KVM_OPTIONAL_VMX_SECONDARY_VM_EXIT_CONTROLS (0) +#define KVM_OPTIONAL_VMX_SECONDARY_VM_EXIT_CONTROLS \ + (SECONDARY_VM_EXIT_SAVE_IA32_FRED | \ + SECONDARY_VM_EXIT_LOAD_IA32_FRED) #define KVM_REQUIRED_VMX_PIN_BASED_VM_EXEC_CONTROL \ (PIN_BASED_EXT_INTR_MASK | \