Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp1601371iog; Tue, 14 Jun 2022 09:09:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz2UUyt3pQnVp4z2M/1g+Ms37XUlBoI8PEYe7gAuonzhyLlIiBvB+nzGN97o3mYP01RwWhX X-Received: by 2002:a63:3184:0:b0:3fc:5893:c866 with SMTP id x126-20020a633184000000b003fc5893c866mr5160282pgx.56.1655222969157; Tue, 14 Jun 2022 09:09:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655222969; cv=none; d=google.com; s=arc-20160816; b=KxrCZzt0EpUUee6Li4wJbrQB0OdZAZuQ5xrVHMJbL3ofK/04xkDk17IxISIstwkFtv xmbZteMuLgqnMX+ae6/Yu1DYMu0baNILbCLaGjRdDa6adVw4yGJNlyJTHmgsrsK5LOb5 C+B5YIRUWS6clM5pDeMpwuuwmfKtUSDfXvfr3J4UhJ0I04KhG8DibaiT5FzXYfzs8dcj YIfs7wCObEN1X4tbs9di5FBtsw3+/SWRijtTtYtvOUSjkmFtsmBgza9XsZR0Gxuh9XUv kIbeoe6Lo20zulllywMBKaTz0GP+PI27K/cMO4U4DvLA6YUO/LvVMm6Aws1WQVJKO587 r8hQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=AjEnIp3i/SaMEtzwhDdPJn8ss5djkc2rozWj+2o5TxI=; b=08tsy0XLJE3BvQWmueRXc4DyA12WN3S+OL7EEjFzaD5R5boeYKDr7flq7MixN94psf bk/oVuRSDDZP/GWC/cKsAz/qMaj/02WIbxZ9UaJmWjVAKD8o2SDzSIVUFwjmUO5o65r1 B8xJfCk05HzGBTQ0w0DK24DdFsMFyA0sfLzXy82uxDsTRg3Sr7kn1poIaAOgJq2Q/TFU B6fwIe6WgZRCEMlyBiXdUz3+kBiWu1FijjoaxTKyK54iVkfizSE/V0+aZ75Ly/QRJaZF eFegVIbvzgANb18SZiOwNQQ4O9oUhZlsdgQiB5S/byz+qy4IYPeZzAfoTQ5QV5BDETWW Kr3g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=nBYw+Em2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id k137-20020a636f8f000000b004051465942fsi15671685pgc.288.2022.06.14.09.09.15; Tue, 14 Jun 2022 09:09:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=nBYw+Em2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237731AbiFNQAn (ORCPT + 99 others); Tue, 14 Jun 2022 12:00:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41888 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345157AbiFNQAk (ORCPT ); Tue, 14 Jun 2022 12:00:40 -0400 Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EE3AD3BBCC for ; Tue, 14 Jun 2022 09:00:37 -0700 (PDT) Received: by mail-pj1-x1034.google.com with SMTP id gd1so8863626pjb.2 for ; Tue, 14 Jun 2022 09:00:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=AjEnIp3i/SaMEtzwhDdPJn8ss5djkc2rozWj+2o5TxI=; b=nBYw+Em2PtAzVr8+taeocf/e1+91IM2pnG7C0wOkrxqNzPnx3YU9Z/gUQiVkiQ+7GK 4AWBKVLbuOGUGOrzVqCRIjjhCz0Gc5rstRVsy/peHrmIysPYIvtJpZkwaYXD2WEB86my /mBugJxiP2N05Vqo8YOXIoqrX392+Be60QmcPR9wL93aJaWZNwbSRg5XiwIsKrjRuJ4Z VzUsh+aq/sp3DwSR5OHWfNxuUPqwFBsnLejRJkICXe33oumtCqbomXrJZ5b2fAanX3Gz 2tcFPAFgMEwjaxJuJRhhePHIScpAYnOSXlJ8smnazEtKPvRa+ISw42JTppqm94Je+xy4 zWAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=AjEnIp3i/SaMEtzwhDdPJn8ss5djkc2rozWj+2o5TxI=; b=esKTEmNoqfJJb9cSxAhFOvuEEZmY4aNQG3LITkt/Ow9pVQvwSuh8mhxtHZvKiw6xpc gDqWECiNZDerThUEUn1TZo69Y+8fzFHBnE+an6O5bXzyRN1olDyQrbT9wzbnEI7UIX2q KN53LNo8OTa95W32p2NXWxlFM7M50s//gUP6lvu82Y5KI2WF9DJeRolFcdUVsvdCFK2q j96MFOGmr63yNwpYfI7CqXdzfrzw6SWkOTqF2b4wGT6wxxXk10GTD71QT3ZfOx4D/zkr TkzTkPuO/gvPboVedrMki9BB9YVevrj4Pup4e2Gn3w8j6FVppVbhzCDQXV6xviCs/XSV Ls5A== X-Gm-Message-State: AJIora8m0qxHJCEmsYA/dj37YAoCsn2kOFaDnYZWT34kmswLeqTzSSBW Y/VW16+55PEled0bpl8s8khEQA== X-Received: by 2002:a17:90b:4a92:b0:1e8:2c09:d008 with SMTP id lp18-20020a17090b4a9200b001e82c09d008mr5366166pjb.169.1655222436939; Tue, 14 Jun 2022 09:00:36 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id ij11-20020a170902ab4b00b0015e8d4eb1f9sm7424820plb.67.2022.06.14.09.00.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jun 2022 09:00:36 -0700 (PDT) Date: Tue, 14 Jun 2022 16:00:32 +0000 From: Sean Christopherson To: Anirudh Rayabharam Cc: Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Ilias Stamatis , Maxim Levitsky , mail@anirudhrb.com, kumarpraveen@linux.microsoft.com, wei.liu@kernel.org, robert.bradford@intel.com, liuwe@microsoft.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] KVM: nVMX: Don't expose TSC scaling to L1 when on Hyper-V Message-ID: References: <20220613161611.3567556-1-anrayabh@linux.microsoft.com> <592ab920-51f3-4794-331f-8737e1f5b20a@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 14, 2022, Anirudh Rayabharam wrote: > On Mon, Jun 13, 2022 at 04:57:49PM +0000, Sean Christopherson wrote: > > On Mon, Jun 13, 2022, Paolo Bonzini wrote: > > > On 6/13/22 18:16, Anirudh Rayabharam wrote: > > > > + if (!kvm_has_tsc_control) > > > > + msrs->secondary_ctls_high &= ~SECONDARY_EXEC_TSC_SCALING; > > > > + > > > > msrs->secondary_ctls_low = 0; > > > > msrs->secondary_ctls_high &= > > > > SECONDARY_EXEC_DESC | > > > > @@ -6667,8 +6670,7 @@ void nested_vmx_setup_ctls_msrs(struct nested_vmx_msrs *msrs, u32 ept_caps) > > > > SECONDARY_EXEC_RDRAND_EXITING | > > > > SECONDARY_EXEC_ENABLE_INVPCID | > > > > SECONDARY_EXEC_RDSEED_EXITING | > > > > - SECONDARY_EXEC_XSAVES | > > > > - SECONDARY_EXEC_TSC_SCALING; > > > > + SECONDARY_EXEC_XSAVES; > > > > /* > > > > > > This is wrong because it _always_ disables SECONDARY_EXEC_TSC_SCALING, > > > even if kvm_has_tsc_control == true. > > > > > > That said, I think a better implementation of this patch is to just add > > > a version of evmcs_sanitize_exec_ctrls that takes a struct > > > nested_vmx_msrs *, and call it at the end of nested_vmx_setup_ctl_msrs like > > > > > > evmcs_sanitize_nested_vmx_vsrs(msrs); > > > > Any reason not to use the already sanitized vmcs_config? I can't think of any > > reason why the nested path should blindly use the raw MSR values from hardware. > > vmcs_config has the sanitized exec controls. But how do we construct MSR > values using them? I was thinking we could use the sanitized controls for the allowed-1 bits, and then take the required-1 bits from the CPU. And then if we wanted to avoid the redundant RDMSRs in a follow-up patch we could add required-1 fields to vmcs_config. Hastily constructed and compile-tested only, proceed with caution :-) --- arch/x86/kvm/vmx/nested.c | 35 ++++++++++++++++++++--------------- arch/x86/kvm/vmx/nested.h | 2 +- arch/x86/kvm/vmx/vmx.c | 5 ++--- 3 files changed, 23 insertions(+), 19 deletions(-) diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c index f5cb18e00e78..67cbb6643efa 100644 --- a/arch/x86/kvm/vmx/nested.c +++ b/arch/x86/kvm/vmx/nested.c @@ -6541,8 +6541,13 @@ static u64 nested_vmx_calc_vmcs_enum_msr(void) * bit in the high half is on if the corresponding bit in the control field * may be on. See also vmx_control_verify(). */ -void nested_vmx_setup_ctls_msrs(struct nested_vmx_msrs *msrs, u32 ept_caps) +void nested_vmx_setup_ctls_msrs(struct vmcs_config *vmcs_conf, u32 ept_caps) { + struct nested_vmx_msrs *msrs = &vmcs_config.nested; + + /* Take the allowed-1 bits from KVM's sanitized VMCS configuration. */ + u32 ignore_high; + /* * Note that as a general rule, the high half of the MSRs (bits in * the control fields which may be 1) should be initialized by the @@ -6559,11 +6564,11 @@ void nested_vmx_setup_ctls_msrs(struct nested_vmx_msrs *msrs, u32 ept_caps) */ /* pin-based controls */ - rdmsr(MSR_IA32_VMX_PINBASED_CTLS, - msrs->pinbased_ctls_low, - msrs->pinbased_ctls_high); + rdmsr(MSR_IA32_VMX_PINBASED_CTLS, msrs->pinbased_ctls_low, ignore_high); msrs->pinbased_ctls_low |= PIN_BASED_ALWAYSON_WITHOUT_TRUE_MSR; + + msrs->pinbased_ctls_high = vmcs_conf->pin_based_exec_ctrl; msrs->pinbased_ctls_high &= PIN_BASED_EXT_INTR_MASK | PIN_BASED_NMI_EXITING | @@ -6574,12 +6579,11 @@ void nested_vmx_setup_ctls_msrs(struct nested_vmx_msrs *msrs, u32 ept_caps) PIN_BASED_VMX_PREEMPTION_TIMER; /* exit controls */ - rdmsr(MSR_IA32_VMX_EXIT_CTLS, - msrs->exit_ctls_low, - msrs->exit_ctls_high); + rdmsr(MSR_IA32_VMX_EXIT_CTLS, msrs->exit_ctls_low, ignore_high); msrs->exit_ctls_low = VM_EXIT_ALWAYSON_WITHOUT_TRUE_MSR; + msrs->exit_ctls_high = vmcs_conf->vmexit_ctrl; msrs->exit_ctls_high &= #ifdef CONFIG_X86_64 VM_EXIT_HOST_ADDR_SPACE_SIZE | @@ -6595,11 +6599,11 @@ void nested_vmx_setup_ctls_msrs(struct nested_vmx_msrs *msrs, u32 ept_caps) msrs->exit_ctls_low &= ~VM_EXIT_SAVE_DEBUG_CONTROLS; /* entry controls */ - rdmsr(MSR_IA32_VMX_ENTRY_CTLS, - msrs->entry_ctls_low, - msrs->entry_ctls_high); + rdmsr(MSR_IA32_VMX_ENTRY_CTLS, msrs->entry_ctls_low, ignore_high); msrs->entry_ctls_low = VM_ENTRY_ALWAYSON_WITHOUT_TRUE_MSR; + + msrs->entry_ctls_high = vmcs_conf->vmentry_ctrl; msrs->entry_ctls_high &= #ifdef CONFIG_X86_64 VM_ENTRY_IA32E_MODE | @@ -6613,11 +6617,11 @@ void nested_vmx_setup_ctls_msrs(struct nested_vmx_msrs *msrs, u32 ept_caps) msrs->entry_ctls_low &= ~VM_ENTRY_LOAD_DEBUG_CONTROLS; /* cpu-based controls */ - rdmsr(MSR_IA32_VMX_PROCBASED_CTLS, - msrs->procbased_ctls_low, - msrs->procbased_ctls_high); + rdmsr(MSR_IA32_VMX_PROCBASED_CTLS, msrs->procbased_ctls_low, ignore_high); msrs->procbased_ctls_low = CPU_BASED_ALWAYSON_WITHOUT_TRUE_MSR; + + msrs->procbased_ctls_high = vmcs_conf->cpu_based_exec_ctrl; msrs->procbased_ctls_high &= CPU_BASED_INTR_WINDOW_EXITING | CPU_BASED_NMI_WINDOW_EXITING | CPU_BASED_USE_TSC_OFFSETTING | @@ -6653,10 +6657,11 @@ void nested_vmx_setup_ctls_msrs(struct nested_vmx_msrs *msrs, u32 ept_caps) */ if (msrs->procbased_ctls_high & CPU_BASED_ACTIVATE_SECONDARY_CONTROLS) rdmsr(MSR_IA32_VMX_PROCBASED_CTLS2, - msrs->secondary_ctls_low, - msrs->secondary_ctls_high); + msrs->secondary_ctls_low, ignore_high); msrs->secondary_ctls_low = 0; + + msrs->secondary_ctls_high = vmcs_conf->cpu_based_2nd_exec_ctrl; msrs->secondary_ctls_high &= SECONDARY_EXEC_DESC | SECONDARY_EXEC_ENABLE_RDTSCP | diff --git a/arch/x86/kvm/vmx/nested.h b/arch/x86/kvm/vmx/nested.h index c92cea0b8ccc..fae047c6204b 100644 --- a/arch/x86/kvm/vmx/nested.h +++ b/arch/x86/kvm/vmx/nested.h @@ -17,7 +17,7 @@ enum nvmx_vmentry_status { }; void vmx_leave_nested(struct kvm_vcpu *vcpu); -void nested_vmx_setup_ctls_msrs(struct nested_vmx_msrs *msrs, u32 ept_caps); +void nested_vmx_setup_ctls_msrs(struct vmcs_config *vmcs_conf, u32 ept_caps); void nested_vmx_hardware_unsetup(void); __init int nested_vmx_hardware_setup(int (*exit_handlers[])(struct kvm_vcpu *)); void nested_vmx_set_vmcs_shadowing_bitmap(void); diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index 9bd86ecccdab..cd0d0ffae0bf 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -7139,7 +7139,7 @@ static int __init vmx_check_processor_compat(void) if (setup_vmcs_config(&vmcs_conf, &vmx_cap) < 0) return -EIO; if (nested) - nested_vmx_setup_ctls_msrs(&vmcs_conf.nested, vmx_cap.ept); + nested_vmx_setup_ctls_msrs(&vmcs_conf, vmx_cap.ept); if (memcmp(&vmcs_config, &vmcs_conf, sizeof(struct vmcs_config)) != 0) { printk(KERN_ERR "kvm: CPU %d feature inconsistency!\n", smp_processor_id()); @@ -8079,8 +8079,7 @@ static __init int hardware_setup(void) setup_default_sgx_lepubkeyhash(); if (nested) { - nested_vmx_setup_ctls_msrs(&vmcs_config.nested, - vmx_capability.ept); + nested_vmx_setup_ctls_msrs(&vmcs_config, vmx_capability.ept); r = nested_vmx_hardware_setup(kvm_vmx_exit_handlers); if (r) base-commit: b821e4ff9e35a8fc999685e8d44c0644cfeaa228 --