Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp3668890imw; Thu, 7 Jul 2022 05:51:59 -0700 (PDT) X-Google-Smtp-Source: AGRyM1uinvJ5ekbRSYYqgWDZAdU1J7RmPZbbdRD43bPqM2F+cXDVgORRsU5WfeD5jXCrRntNf3+v X-Received: by 2002:a05:6402:4387:b0:435:94c6:716d with SMTP id o7-20020a056402438700b0043594c6716dmr62473756edc.298.1657198318903; Thu, 07 Jul 2022 05:51:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657198318; cv=none; d=google.com; s=arc-20160816; b=iTVexvWjWx6mlogH/8UHVUC4EAg06yjySX+qiHO6WfGTnL+p7kzaPvy7Pq37mORDb2 Fx2kHnBFFD8ckSB+mxGuV+01UkgGHIlWFqM/NMuXxqnomiIigIMtOCJiXJb4SDpbjYQh RSKf+F6lkVBCpRBQCyiocjTur6F9TSaCUC1zBKPuDFET8Wgt+y2HHuWAjg5WisoX2JR/ tBu4G+T7/RKXB6dwAZePudd7bJu7FlRAMyu0n2EDlr7eCf44W+SzXE4DYenZecvVnTdn qwBN8AAeGrNmgJ+6y5qIt/ukUvqCJAmqru6/wuDjRPEYqOAux7sNPmWe8ZXLE9/q0elb 1KIw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:dkim-signature; bh=7taFVEbaeBa5qKeQW2zkf18xKccNfBkJ+gfCJ/fDRBM=; b=pZfVnFlX9PbBgbjzfN7YiNYD1zEbHfr935qDWCwqhothJMVjK0bISKn5C/4h+38MLG nDX79T2cPLqKj8vzs42yqvV1G6kltU4RM+xDP2blT8YAqPe0hDriZ7sNjQm/v3anXqRA bvVVgU+Yn20JcSONG0Mr9Sfr0IibtKBIiZEihDi8/fskjCGzTmY4uVGvYUhuf0vCEJL1 NDyuKf/MAWA0EQJ46kb/cl71Zxy14hUTQdQ/A/q66i1trWzx5v5uG06IH/WD8JRGjxZO mQRFSvM5zEC1LFQ64CAk0r6BwJKVq8l5Jzv+Lj0VM/WRq8n2/s6BQ1g6MDCwiJE3X5KV v+JQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=A5yTOdFU; 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=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x19-20020a1709064bd300b00722e3529906si18969825ejv.324.2022.07.07.05.51.32; Thu, 07 Jul 2022 05:51:58 -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=@redhat.com header.s=mimecast20190719 header.b=A5yTOdFU; 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=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235381AbiGGMad (ORCPT + 99 others); Thu, 7 Jul 2022 08:30:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59726 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234774AbiGGMab (ORCPT ); Thu, 7 Jul 2022 08:30:31 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id A72FA15FC9 for ; Thu, 7 Jul 2022 05:30:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1657197028; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=7taFVEbaeBa5qKeQW2zkf18xKccNfBkJ+gfCJ/fDRBM=; b=A5yTOdFUvyVHHnzpqwaNnYf+UkYWY1ETu59Fp0yRZjUInr9aV2btx08mRBVsLhBRuHveJ3 ouaNv5Ag+0aQKMx+k1GTB0znf33H4NRFyUtGD8FqnmmbiWEfWH4MCi8jcP4ngOcGAp5bBQ n+r6fbD5YhW6m1ahxZp9dF0wtS6Ut0o= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-388-t2o0RlUJOrS7syYnDIAFvA-1; Thu, 07 Jul 2022 08:30:27 -0400 X-MC-Unique: t2o0RlUJOrS7syYnDIAFvA-1 Received: by mail-wm1-f70.google.com with SMTP id v67-20020a1cac46000000b003a2be9fa09cso2542406wme.3 for ; Thu, 07 Jul 2022 05:30:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=7taFVEbaeBa5qKeQW2zkf18xKccNfBkJ+gfCJ/fDRBM=; b=aePBL9H3x4FcOx0GJq816hjHxMkgrerp3vlds2JE23X51D99UODJCxaEXswpqpHePP 6nzHDMhLUme9FgomRyxsLuRSB5AF8QCqdEATVDjp1Nx8qQk8010MkbXKM7O01N5hJ3kM 32aK2At9k1Ef6IBSvNuOwxlS2k+l40C//A6BGQflo1qqwcsxaUkE94em0zG2r8kmKy9B Dp9lIqfjHbxI8xH74dsnsR5uE8pKQ+7LFRajaEEaYzRPPs4RM8GPf0hRvwwtsVhpRJu7 YCbz16pbhBRdVIS7Eq4QEs1/3yw2Sz/D1NUm3Dwxj8r4V0f680xbAZJAlwkJIPB6EtiC /vig== X-Gm-Message-State: AJIora/xVhyB8nhoXaYygPyUMji7+rErNhM9lw6lLtKwTQYkNgKyCFkj +sXyyZm3RKT91OqSjVGgrWm1Q3nYSLh7DGAkuGPQgzPdyGMGawMUSXWyook7Ywkt+4ccv2nVHcN P6ZP0XqHK8HvJycLZKPshSf9M3owP/Y/jXYhkmkRHUwCEX7skH2mBJgDZl4qALRKxmL7WiCmgXr Wo X-Received: by 2002:a05:600c:3d10:b0:3a0:4956:9a84 with SMTP id bh16-20020a05600c3d1000b003a049569a84mr4247283wmb.133.1657197026672; Thu, 07 Jul 2022 05:30:26 -0700 (PDT) X-Received: by 2002:a05:600c:3d10:b0:3a0:4956:9a84 with SMTP id bh16-20020a05600c3d1000b003a049569a84mr4247233wmb.133.1657197026292; Thu, 07 Jul 2022 05:30:26 -0700 (PDT) Received: from fedora (nat-2.ign.cz. [91.219.240.2]) by smtp.gmail.com with ESMTPSA id m1-20020a056000008100b0021d7ff34df7sm3824536wrx.117.2022.07.07.05.30.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Jul 2022 05:30:25 -0700 (PDT) From: Vitaly Kuznetsov To: Jim Mattson Cc: kvm@vger.kernel.org, Paolo Bonzini , Sean Christopherson , Anirudh Rayabharam , Wanpeng Li , Maxim Levitsky , linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 24/28] KVM: nVMX: Use sanitized allowed-1 bits for VMX control MSRs In-Reply-To: References: <20220629150625.238286-1-vkuznets@redhat.com> <20220629150625.238286-25-vkuznets@redhat.com> Date: Thu, 07 Jul 2022 14:30:24 +0200 Message-ID: <87zghlp0kf.fsf@redhat.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE 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 Jim Mattson writes: > On Wed, Jun 29, 2022 at 8:07 AM Vitaly Kuznetsov wrote: >> >> Using raw host MSR values for setting up nested VMX control MSRs is >> incorrect as some features need to disabled, e.g. when KVM runs as >> a nested hypervisor on Hyper-V and uses Enlightened VMCS or when a >> workaround for IA32_PERF_GLOBAL_CTRL is applied. For non-nested VMX, this >> is done in setup_vmcs_config() and the result is stored in vmcs_config. >> Use it for setting up allowed-1 bits in nested VMX MSRs too. >> >> Suggested-by: Sean Christopherson >> Signed-off-by: Vitaly Kuznetsov >> --- >> arch/x86/kvm/vmx/nested.c | 34 ++++++++++++++++------------------ >> arch/x86/kvm/vmx/nested.h | 2 +- >> arch/x86/kvm/vmx/vmx.c | 5 ++--- >> 3 files changed, 19 insertions(+), 22 deletions(-) >> >> diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c >> index 88625965f7b7..e5b19b5e6cab 100644 >> --- a/arch/x86/kvm/vmx/nested.c >> +++ b/arch/x86/kvm/vmx/nested.c >> @@ -6565,8 +6565,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_conf->nested; >> + >> + /* Take the allowed-1 bits from KVM's sanitized VMCS configuration. */ >> + u32 ignore_high; >> + > > Giving this object a name seems gauche. > >> /* >> * 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 >> @@ -6583,11 +6588,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); > > Perhaps "(u32){0}" rather than "ignore_high"? > While this certainly looks like a cool trick (thanks!), both rdmsr() and 'ignore_high' are gone later in the series. I will, however, adopt the change, even if just to show off) >> msrs->pinbased_ctls_low |= >> PIN_BASED_ALWAYSON_WITHOUT_TRUE_MSR; > > NYC, but why is this one '|=', and the rest just '='? Does there exist > a CPU that requires more than PIN_BASED_ALWAYSON_WITHOUT_TRUE_MSR? > Looking at the commit which introduced this, commit eabeaaccfca0ed61b8e00a09b8cfa703c4f11b59 Author: Jan Kiszka Date: Wed Mar 13 11:30:50 2013 +0100 KVM: nVMX: Clean up and fix pin-based execution controls I don't think '|=' is needed. It is, of course, possible that when KVM is running nested, required-1 bits are mangled by the underlying hypervisor but this is a) unlikely b) will only be observed by KVM's L1 (which means we're talking about 3-level nesting here). Let's be brave and 'fix' '|=' here. >> + >> + msrs->pinbased_ctls_high = vmcs_conf->pin_based_exec_ctrl; >> msrs->pinbased_ctls_high &= >> PIN_BASED_EXT_INTR_MASK | >> PIN_BASED_NMI_EXITING | >> @@ -6598,12 +6603,10 @@ 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); >> 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 | >> @@ -6619,11 +6622,10 @@ 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); >> 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 | >> @@ -6637,11 +6639,10 @@ 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); >> 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 | >> @@ -6675,12 +6676,9 @@ void nested_vmx_setup_ctls_msrs(struct nested_vmx_msrs *msrs, u32 ept_caps) >> * depend on CPUID bits, they are added later by >> * vmx_vcpu_after_set_cpuid. >> */ >> - 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 = 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 5f7ef1f8d2c6..5d4158b7421c 100644 >> --- a/arch/x86/kvm/vmx/vmx.c >> +++ b/arch/x86/kvm/vmx/vmx.c >> @@ -7310,7 +7310,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()); >> @@ -8285,8 +8285,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) >> -- >> 2.35.3 >> > -- Vitaly