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 X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B2FE5C10DCE for ; Sat, 7 Mar 2020 00:28:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 91975206E2 for ; Sat, 7 Mar 2020 00:28:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726704AbgCGA2y (ORCPT ); Fri, 6 Mar 2020 19:28:54 -0500 Received: from mga11.intel.com ([192.55.52.93]:47074 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726300AbgCGA2y (ORCPT ); Fri, 6 Mar 2020 19:28:54 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Mar 2020 16:28:53 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,524,1574150400"; d="scan'208";a="440297238" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.202]) by fmsmga005.fm.intel.com with ESMTP; 06 Mar 2020 16:28:53 -0800 Date: Fri, 6 Mar 2020 16:28:53 -0800 From: Sean Christopherson To: Krish Sadhukhan Cc: Vitaly Kuznetsov , Paolo Bonzini , Jim Mattson , Wanpeng Li , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 2/2] KVM: VMX: untangle VMXON revision_id setting when using eVMCS Message-ID: <20200307002852.GA28225@linux.intel.com> References: <20200306130215.150686-1-vkuznets@redhat.com> <20200306130215.150686-3-vkuznets@redhat.com> <908345f1-9bfd-004f-3ba6-0d6dce67d11e@oracle.com> <20200306230747.GA27868@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 06, 2020 at 03:57:25PM -0800, Krish Sadhukhan wrote: > > On 3/6/20 3:07 PM, Sean Christopherson wrote: > >On Fri, Mar 06, 2020 at 02:20:13PM -0800, Krish Sadhukhan wrote: > >>>@@ -2599,7 +2607,7 @@ void free_loaded_vmcs(struct loaded_vmcs *loaded_vmcs) > >>> int alloc_loaded_vmcs(struct loaded_vmcs *loaded_vmcs) > >>> { > >>>- loaded_vmcs->vmcs = alloc_vmcs(false); > >>>+ loaded_vmcs->vmcs = alloc_vmcs(VMCS_REGION); > >>> if (!loaded_vmcs->vmcs) > >>> return -ENOMEM; > >>>@@ -2652,25 +2660,13 @@ static __init int alloc_vmxon_regions(void) > >>> for_each_possible_cpu(cpu) { > >>> struct vmcs *vmcs; > >>>- vmcs = alloc_vmcs_cpu(false, cpu, GFP_KERNEL); > >>>+ /* The VMXON region is really just a special type of VMCS. */ > >> > >>Not sure if this is the right way to correlate the two. > >> > >>AFAIU, the SDM calls VMXON region as a memory area that holds the VMCS data > >>structure and it calls VMCS the data structure that is used by software to > >>switch between VMX root-mode and not-root-mode. So VMXON is a memory area > >>whereas VMCS is the structure of the data that resides in that memory area. > >> > >>So if we follow this interpretation, your enum should rather look like, > >> > >>enum vmcs_type { > >>+    VMCS, > >>+    EVMCS, > >>+    SHADOW_VMCS > >No (to the EVMCS suggestion), because this allocation needs to happen for > >!eVMCS. The SDM never explictly calls the VMXON region a VMCS, but it's > >just being coy. E.g. VMCLEAR doesn't fail if you point it at random > >memory, but point it at the VMXON region and it yells. > > > >We could call it VMXON_VMCS if that helps. > > Are you saying, > > + enum vmcs_type { > +     VMXON_REGION, > +     VMXON_VMCS, > +     SHADOW_VMCS_REGION, > +}; > > ? > > In that case, "VMXON_REGION" and "VMXON_VMCS" are no different according to > your explanation. enum vmcs_type { VMXON_VMCS, VMCS, SHADOW_VMCS, }; alloc_vmcs_cpu() does more than just allocate the memory, it also initializes the data structure, e.g. "allocate and initalize a VMXON VMCS", > > The SDM does call the memory > >allocation for regular VMCSes a "VMCS region": > > > > A logical processor associates a region in memory with each VMCS. This > > region is called the VMCS region. > > > >I don't think I've ever heard anyone differentiate that two though, i.e. > >VMCS is used colloquially to mean both the data structure itself and the > >memory region containing the data structure. > > > >>>+ vmcs = alloc_vmcs_cpu(VMXON_REGION, cpu, GFP_KERNEL); > >>> if (!vmcs) { > >>> free_vmxon_regions(); > >>> return -ENOMEM; > >>> } > >>>- /* > >>>- * When eVMCS is enabled, alloc_vmcs_cpu() sets > >>>- * vmcs->revision_id to KVM_EVMCS_VERSION instead of > >>>- * revision_id reported by MSR_IA32_VMX_BASIC. > >>>- * > >>>- * However, even though not explicitly documented by > >>>- * TLFS, VMXArea passed as VMXON argument should > >>>- * still be marked with revision_id reported by > >>>- * physical CPU. > >>>- */ > >>>- if (static_branch_unlikely(&enable_evmcs)) > >>>- vmcs->hdr.revision_id = vmcs_config.revision_id; > >>>- > >>> per_cpu(vmxarea, cpu) = vmcs; > >>> } > >>> return 0; > >>>diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h > >>>index e64da06c7009..a5eb92638ac2 100644 > >>>--- a/arch/x86/kvm/vmx/vmx.h > >>>+++ b/arch/x86/kvm/vmx/vmx.h > >>>@@ -489,16 +489,22 @@ static inline struct pi_desc *vcpu_to_pi_desc(struct kvm_vcpu *vcpu) > >>> return &(to_vmx(vcpu)->pi_desc); > >>> } > >>>-struct vmcs *alloc_vmcs_cpu(bool shadow, int cpu, gfp_t flags); > >>>+enum vmcs_type { > >>>+ VMXON_REGION, > >>>+ VMCS_REGION, > >>>+ SHADOW_VMCS_REGION, > >>>+}; > >>>+ > >>>+struct vmcs *alloc_vmcs_cpu(enum vmcs_type type, int cpu, gfp_t flags); > >>> void free_vmcs(struct vmcs *vmcs); > >>> int alloc_loaded_vmcs(struct loaded_vmcs *loaded_vmcs); > >>> void free_loaded_vmcs(struct loaded_vmcs *loaded_vmcs); > >>> void loaded_vmcs_init(struct loaded_vmcs *loaded_vmcs); > >>> void loaded_vmcs_clear(struct loaded_vmcs *loaded_vmcs); > >>>-static inline struct vmcs *alloc_vmcs(bool shadow) > >>>+static inline struct vmcs *alloc_vmcs(enum vmcs_type type) > >>> { > >>>- return alloc_vmcs_cpu(shadow, raw_smp_processor_id(), > >>>+ return alloc_vmcs_cpu(type, raw_smp_processor_id(), > >>> GFP_KERNEL_ACCOUNT); > >>> }