From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5B708C19F2A for ; Thu, 28 Jul 2022 22:13:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231886AbiG1WNf (ORCPT ); Thu, 28 Jul 2022 18:13:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52340 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229570AbiG1WNd (ORCPT ); Thu, 28 Jul 2022 18:13:33 -0400 Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D2E3C785AB for ; Thu, 28 Jul 2022 15:13:32 -0700 (PDT) Received: by mail-pl1-x62a.google.com with SMTP id o3so2972057ple.5 for ; Thu, 28 Jul 2022 15:13:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc; bh=l+5rBl2AK20PKGSH65YU4OKpcYRMAbAXO924wPV6Eik=; b=G8r95Q5hVuJdINZ5QqtY3e6DleLLl6mJ8NIAFZtg9iYDfXUfTrEfqm91RDT9EPqoXH v/h2kLU9U4IM03G3Y3Syt3PeuvRfeMeHuytOAsJFNn4HkAS0CWdFNUNxpK9Xqm1z69Yz ofZSMnadJWIBesKXLIWCCNeW5w5zzy2Lgrph55zYPmUWos4Sx638KPd/A2K+CbOKnexw FJMZw6w3cOeJydQGZ89N8ZOyWsVESGDUsZSKlzzPSoRmAH3b5eDw0j/SASSXovoly4EG pgoJKE3WAWl6SLP4OioP1JsCteYpM+rVXi/iwQyxpJuYAWSRfKaqTbRU2udnrO2F6eKS 42ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc; bh=l+5rBl2AK20PKGSH65YU4OKpcYRMAbAXO924wPV6Eik=; b=ZIhRk+GIXA60f/vWxAIbUjE06Af9sXKm6UK4BJTP3Z8dwE8JI+7bQLpCdsKlpxDjmy SwT33p7fgMMy7G13XHxnFwT7pyfx6Z9pJyIbrNfaPAqsKA7VAmq3gwQvb9ZoA3FcO6t1 A3ycm03L9RJ3+9EIN1ZOxZJUYRfuOmy/jfP/Vz64PcO3Eyupix9/uBngGfgCgzITTtgM p/f4TCJ7eOivoOoduy6tLS5vlvbbI7nhSPElO0i+3WWPl6AIn+YdCF5bE1hAOWZKNhff OjonPoN1zGTJ3V5s5jMtjteksNJvxmrKzQTPhTDMhXWqUargizB/TzfeX3d5CNmQnozX y5uw== X-Gm-Message-State: ACgBeo1rgqzFzLPpYjv9OY1xwc0Sghwe84fd268bXPTL4HFnMMoC6mFx CDop6XhiqQq6Zd05oDySeToDAQ== X-Google-Smtp-Source: AA6agR6+VxdW2AncFaQzR2JNzm9++SeJViANFTSi6sftkYixtXxow5mvN8+au9fN/WbG/faRu1Swfg== X-Received: by 2002:a17:902:cf06:b0:16b:cc33:5bce with SMTP id i6-20020a170902cf0600b0016bcc335bcemr864483plg.152.1659046412192; Thu, 28 Jul 2022 15:13:32 -0700 (PDT) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id 13-20020a170902c24d00b0016db7f49cc2sm1826843plg.115.2022.07.28.15.13.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Jul 2022 15:13:31 -0700 (PDT) Date: Thu, 28 Jul 2022 22:13:27 +0000 From: Sean Christopherson To: Paolo Bonzini Cc: Vitaly Kuznetsov , kvm@vger.kernel.org, Anirudh Rayabharam , Wanpeng Li , Jim Mattson , Maxim Levitsky , linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 09/25] KVM: VMX: nVMX: Support TSC scaling and PERF_GLOBAL_CTRL with enlightened VMCS Message-ID: References: <20220714091327.1085353-1-vkuznets@redhat.com> <20220714091327.1085353-10-vkuznets@redhat.com> <48de7ea7-fc1a-6a83-3d6f-e04d26ea2f05@redhat.com> <870d507d-a516-5601-4d21-2bfd571cf008@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <870d507d-a516-5601-4d21-2bfd571cf008@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 28, 2022, Paolo Bonzini wrote: > On 7/25/22 20:18, Sean Christopherson wrote: > > > I kind of like the idea of having a two-dimensional array based on the enums > > > instead of switch statements, so for now I'll keep Vitaly's enums. > > I don't have a strong opinion on using a 2d array, but unless I'm missing something, > > that's nowhere to be found in this patch. IMO, having the enums without them > > providing any unique value is silly and obfuscates the code. > > Yeah, like this: > > diff --git a/arch/x86/kvm/vmx/evmcs.c b/arch/x86/kvm/vmx/evmcs.c > index d8da4026c93d..8055128d8638 100644 > --- a/arch/x86/kvm/vmx/evmcs.c > +++ b/arch/x86/kvm/vmx/evmcs.c > @@ -342,9 +342,10 @@ uint16_t nested_get_evmcs_version(struct kvm_vcpu *vcpu) > return 0; > } > -enum evmcs_v1_revision { > +enum evmcs_revision { > EVMCSv1_2016, > EVMCSv1_2022, > + EVMCS_REVISION_MAX, > }; > enum evmcs_unsupported_ctrl_type { > @@ -353,13 +354,37 @@ enum evmcs_unsupported_ctrl_type { > EVMCS_2NDEXEC, > EVMCS_PINCTRL, > EVMCS_VMFUNC, > + EVMCS_CTRL_MAX, > +}; > + > +static u32 evmcs_unsupported_ctls[EVMCS_CTRL_MAX][EVMCS_REVISION_MAX] = { Can this be const? > + [EVMCS_EXIT_CTLS] = { > + [EVMCSv1_2016] = EVMCS1_UNSUPPORTED_VMEXIT_CTRL | VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL, > + [EVMCSv1_2022] = EVMCS1_UNSUPPORTED_VMEXIT_CTRL, > + }, > + [EVMCS_ENTRY_CTLS] = { > + [EVMCSv1_2016] = EVMCS1_UNSUPPORTED_VMENTRY_CTRL | VM_ENTRY_LOAD_IA32_PERF_GLOBAL_CTRL, > + [EVMCSv1_2022] = EVMCS1_UNSUPPORTED_VMENTRY_CTRL, > + }, > + [EVMCS_2NDEXEC] = { > + [EVMCSv1_2016] = EVMCS1_UNSUPPORTED_2NDEXEC | SECONDARY_EXEC_TSC_SCALING, > + [EVMCSv1_2022] = EVMCS1_UNSUPPORTED_2NDEXEC, > + }, > + [EVMCS_PINCTRL] = { > + [EVMCSv1_2016] = EVMCS1_UNSUPPORTED_PINCTRL, > + [EVMCSv1_2022] = EVMCS1_UNSUPPORTED_PINCTRL, > + }, > + [EVMCS_VMFUNC] = { > + [EVMCSv1_2016] = EVMCS1_UNSUPPORTED_VMFUNC, > + [EVMCSv1_2022] = EVMCS1_UNSUPPORTED_VMFUNC, > + }, > }; ... > + return evmcs_unsupported_ctls[ctrl_type][evmcs_rev]; > } The only flaw in this is if KVM gets handed a CPUID model that enumerates support for 2025 (or whenever the next update comes) but not 2022. Hmm, though if Microsoft defines each new "version" as a full superset, then even that theoretical bug goes away. I'm happy to be optimistic for once and give this a shot. I definitely like that it makes it easier to see the deltas between versions.