Received: by 2002:ac0:cd04:0:0:0:0:0 with SMTP id w4csp73619imn; Fri, 1 Jul 2022 10:10:56 -0700 (PDT) X-Google-Smtp-Source: AGRyM1uLOTa/97dyc4uFQsoLbU+bmMsP03VyS+ZnTyFEeeJ3xe5+L/aFASRANRn+hsJKO9W15ni+ X-Received: by 2002:a17:90b:164a:b0:1ec:b990:17bf with SMTP id il10-20020a17090b164a00b001ecb99017bfmr18178405pjb.171.1656695456435; Fri, 01 Jul 2022 10:10:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656695456; cv=none; d=google.com; s=arc-20160816; b=hJIznpys2w9EwLsWQdOhR03BuV1CmMDDafoT0MPIg4Nl2wXdHuhSPMS+f+Y8MV3dhE F05WIjxEMI4GlQkWrqv7G5Tntc8KBvJoMrdMc1247oEt/8qNv1YL//KJC9ll8UhlOdYO SkZ4XrKfwmDAcPC8o2gJiqGp+emUyNeD5vqX1CLao16hClDDRzYMfiqtDYI//SlVRN45 pSRDtJhQfhfBCbAj9WcPoxD+sgvHEnd7ULZnjI1tNnbxER5fyjfTz6g2Ckn0LxHzmy35 hT9teaQJFXAeRlku45cFokXuOTBhh/4uiimFaxmptC9acRc7VMMmszs5kJ/d/CZrsNGQ zT3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=K26MwrAuUteiZyWEOzDvbm+FiqummBqIOV2xCXu76yM=; b=r5DHVXKPrWpgbz0UaNEsBEstP9AL2AuTGVN3GGotZQd2vZpuKBSzLDVEsyzh7tfFHX fFbZoHNTQhr2y+lgYD078GWJrO/quAuIHo6d31M47qwYrsX9LWA4M7vDdr85MuChe8YM EP5ZDz9aj1polHGDqi01H6bpcHw7ID3E3OrGjxRLa3OXDCf5CgEaY0jlSOl91Y99TOvP VvzqO4kTBk8t3jf3B6QP7FgkMS9zQFRCWAPe2j/1/ZpjnR1oJTAM60k8xXmYRpA4e3ox iiYfzDXSWnjHU3YSmvSS3AD42Y8Uu0cjVsMLzvntc9Tha0A3B44G+eCxRHADjZkMM1p4 ovJg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=Ixmg3++r; 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 l15-20020a170903244f00b0016a3085552csi37261468pls.521.2022.07.01.10.10.29; Fri, 01 Jul 2022 10:10:56 -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=Ixmg3++r; 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 S232080AbiGAQ0r (ORCPT + 99 others); Fri, 1 Jul 2022 12:26:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49176 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232118AbiGAQ0p (ORCPT ); Fri, 1 Jul 2022 12:26:45 -0400 Received: from mail-oa1-x2d.google.com (mail-oa1-x2d.google.com [IPv6:2001:4860:4864:20::2d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A2F7C41602 for ; Fri, 1 Jul 2022 09:26:43 -0700 (PDT) Received: by mail-oa1-x2d.google.com with SMTP id 586e51a60fabf-f2a4c51c45so4156434fac.9 for ; Fri, 01 Jul 2022 09:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=K26MwrAuUteiZyWEOzDvbm+FiqummBqIOV2xCXu76yM=; b=Ixmg3++rgJ8IUJE7we0mxCXtZMmmsiY6hst+fVyftGVwB60OGjmkQodnPu56rSx26x AzHgNxP6GiQdmczQ7Bp8/Zni0M9iKk6KvYkBtr8/Ur1zNzuArnrGSaZfQE7+ehh+AqGz O7VW/P4YJkz0y6i59iigxbpO10P9ogp7SYgzb7y8uZoZtvG2EQel/v4LgNCfsuAV/v4O O8afSWKTcvg0JsuU+fKaxZqdlnTIDaViI8MdxbHcDLUAdLHyneysHfldfmbXen1l8tI5 o0WMlhmThr7f4GF3lf9xjsTeiEv3tx93rUY/C8Dk19cQ/1/Asy4Rsq/pcnLA6LEsjLNl azsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=K26MwrAuUteiZyWEOzDvbm+FiqummBqIOV2xCXu76yM=; b=bCCjup50+1dwIieBgXg+JogQhAF+nSuvq8TbcVy0dKzmpsbr2PUcvAdradoSvFaJEi jNjJ6t6vg8G0paekyvw0k0s1RRuQ+5VBK4yn+pct3h0+9ZEqWRzXIp/ED0Qk+jWj2yCW UnHysz/PfMKVp7FAGh2s43x8RpHfDP8viMq/3PzHtpIlfkHyf3QsWARhhz7MzW3CxdYZ vPoyi3+shMkyw7YvFOKXXrblBdJJ4J63nzryI8oTVLlFMPqGNJVEZYLbaYGJ/4WiQgg1 tCwk1BzWnIsVNGGK8gfGVSXsiKYErA7oKqvQmrafAt8BYwrIs66oUPVT7KARc5rEBRXI tdjg== X-Gm-Message-State: AJIora9FmVmUZroFcFlvvlFBrHlxlgul5bMOZTPrI1q2Sw2Sb24O0cR1 km8vosIb7vf+XGASOGIgfewFr4zHs7UWAijslCKYvzAXqDSUUQ== X-Received: by 2002:a05:6870:d3c7:b0:104:9120:8555 with SMTP id l7-20020a056870d3c700b0010491208555mr8825797oag.181.1656692802766; Fri, 01 Jul 2022 09:26:42 -0700 (PDT) MIME-Version: 1.0 References: <20220629150625.238286-1-vkuznets@redhat.com> <20220629150625.238286-24-vkuznets@redhat.com> In-Reply-To: <20220629150625.238286-24-vkuznets@redhat.com> From: Jim Mattson Date: Fri, 1 Jul 2022 09:26:31 -0700 Message-ID: Subject: Re: [PATCH v2 23/28] KVM: VMX: Move LOAD_IA32_PERF_GLOBAL_CTRL errata handling out of setup_vmcs_config() To: Vitaly Kuznetsov 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 Content-Type: text/plain; charset="UTF-8" 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 Wed, Jun 29, 2022 at 8:07 AM Vitaly Kuznetsov wrote: > > As a preparation to reusing the result of setup_vmcs_config() for setting > up nested VMX control MSRs, move LOAD_IA32_PERF_GLOBAL_CTRL errata handling > to vmx_vmexit_ctrl()/vmx_vmentry_ctrl() and print the warning from > hardware_setup(). While it seems reasonable to not expose > LOAD_IA32_PERF_GLOBAL_CTRL controls to L1 hypervisor on buggy CPUs, > such change would inevitably break live migration from older KVMs > where the controls are exposed. Keep the status quo for know, L1 hypervisor > itself is supposed to take care of the errata. It can only do that if L1 doesn't lie about the model. This is why F/M/S checks are, in general, evil. > Signed-off-by: Vitaly Kuznetsov > --- > arch/x86/kvm/vmx/vmx.c | 62 ++++++++++++++++++++++++++---------------- > 1 file changed, 38 insertions(+), 24 deletions(-) > > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c > index fb58b0be953d..5f7ef1f8d2c6 100644 > --- a/arch/x86/kvm/vmx/vmx.c > +++ b/arch/x86/kvm/vmx/vmx.c > @@ -2416,6 +2416,31 @@ static bool cpu_has_sgx(void) > return cpuid_eax(0) >= 0x12 && (cpuid_eax(0x12) & BIT(0)); > } > > +/* > + * Some cpus support VM_{ENTRY,EXIT}_IA32_PERF_GLOBAL_CTRL but they > + * can't be used due to an errata where VM Exit may incorrectly clear Nit: erratum (singular), or drop the 'an' to refer to errata (plural). > + * IA32_PERF_GLOBAL_CTRL[34:32]. Workaround the errata by using the Nit: workaround (one word) is a noun. The verb form is "work around." > + * MSR load mechanism to switch IA32_PERF_GLOBAL_CTRL. > + */ > +static bool cpu_has_perf_global_ctrl_bug(void) > +{ > + if (boot_cpu_data.x86 == 0x6) { > + switch (boot_cpu_data.x86_model) { > + case 26: /* AAK155 */ > + case 30: /* AAP115 */ > + case 37: /* AAT100 */ > + case 44: /* BC86,AAY89,BD102 */ > + case 46: /* BA97 */ Nit: Replace decimal model numbers with mnemonics. See https://lore.kernel.org/kvm/20220629222221.986645-1-jmattson@google.com/. > + return true; > + default: > + break; > + } > + } > + > + return false; > +} Is it worth either (a) memoizing the result, or (b) toggling a static branch? Or am I prematurely optimizing? > + > + > static __init int adjust_vmx_controls(u32 ctl_min, u32 ctl_opt, > u32 msr, u32 *result) > { > @@ -2572,30 +2597,6 @@ static __init int setup_vmcs_config(struct vmcs_config *vmcs_conf, > _vmexit_control &= ~x_ctrl; > } > > - /* > - * Some cpus support VM_{ENTRY,EXIT}_IA32_PERF_GLOBAL_CTRL but they > - * can't be used due to an errata where VM Exit may incorrectly clear > - * IA32_PERF_GLOBAL_CTRL[34:32]. Workaround the errata by using the > - * MSR load mechanism to switch IA32_PERF_GLOBAL_CTRL. > - */ > - if (boot_cpu_data.x86 == 0x6) { > - switch (boot_cpu_data.x86_model) { > - case 26: /* AAK155 */ > - case 30: /* AAP115 */ > - case 37: /* AAT100 */ > - case 44: /* BC86,AAY89,BD102 */ > - case 46: /* BA97 */ > - _vmentry_control &= ~VM_ENTRY_LOAD_IA32_PERF_GLOBAL_CTRL; > - _vmexit_control &= ~VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL; > - pr_warn_once("kvm: VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL " > - "does not work properly. Using workaround\n"); > - break; > - default: > - break; > - } > - } > - > - > rdmsr(MSR_IA32_VMX_BASIC, vmx_msr_low, vmx_msr_high); > > /* IA-32 SDM Vol 3B: VMCS size is never greater than 4kB. */ > @@ -4188,6 +4189,10 @@ static u32 vmx_vmentry_ctrl(void) > VM_ENTRY_LOAD_IA32_EFER | > VM_ENTRY_IA32E_MODE); > > + > + if (cpu_has_perf_global_ctrl_bug()) > + vmentry_ctrl &= ~VM_ENTRY_LOAD_IA32_PERF_GLOBAL_CTRL; > + > return vmentry_ctrl; > } > > @@ -4202,6 +4207,10 @@ static u32 vmx_vmexit_ctrl(void) > if (vmx_pt_mode_is_system()) > vmexit_ctrl &= ~(VM_EXIT_PT_CONCEAL_PIP | > VM_EXIT_CLEAR_IA32_RTIT_CTL); > + > + if (cpu_has_perf_global_ctrl_bug()) > + vmexit_ctrl &= ~VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL; > + > /* Loading of EFER and PERF_GLOBAL_CTRL are toggled dynamically */ > return vmexit_ctrl & > ~(VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL | VM_EXIT_LOAD_IA32_EFER); > @@ -8117,6 +8126,11 @@ static __init int hardware_setup(void) > if (setup_vmcs_config(&vmcs_config, &vmx_capability) < 0) > return -EIO; > > + if (cpu_has_perf_global_ctrl_bug()) { > + pr_warn_once("kvm: VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL " > + "does not work properly. Using workaround\n"); > + } > + > if (boot_cpu_has(X86_FEATURE_NX)) > kvm_enable_efer_bits(EFER_NX); > > -- > 2.35.3 >