From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Jim Mattson <jmattson@google.com>,
Wanpeng Li <wanpengli@tencent.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] KVM: VMX: untangle VMXON revision_id setting when using eVMCS
Date: Thu, 5 Mar 2020 12:10:00 -0800 [thread overview]
Message-ID: <20200305201000.GQ11500@linux.intel.com> (raw)
In-Reply-To: <20200305183725.28872-3-vkuznets@redhat.com>
On Thu, Mar 05, 2020 at 07:37:25PM +0100, Vitaly Kuznetsov wrote:
> As stated in alloc_vmxon_regions(), VMXON region needs to be tagged with
> revision id from MSR_IA32_VMX_BASIC even in case of eVMCS. The logic to
> do so is not very straightforward: first, we set
> hdr.revision_id = KVM_EVMCS_VERSION in alloc_vmcs_cpu() just to reset it
> back to vmcs_config.revision_id in alloc_vmxon_regions(). Simplify this by
> introducing 'enum vmcs_type' parameter to alloc_vmcs_cpu().
>
> No functional change intended.
>
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> ---
...
> + * However, even though not explicitly documented by TLFS, VMXArea
> + * passed as VMXON argument should still be marked with revision_id
> + * reported by physical CPU.
LOL, nice.
> + */
> + if (type != VMXON_REGION && static_branch_unlikely(&enable_evmcs))
> vmcs->hdr.revision_id = KVM_EVMCS_VERSION;
> else
> vmcs->hdr.revision_id = vmcs_config.revision_id;
>
> - if (shadow)
> + if (type == SHADOW_VMCS_REGION)
> vmcs->hdr.shadow_vmcs = 1;
> return vmcs;
> }
> -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);
> @@ -498,8 +504,8 @@ void loaded_vmcs_clear(struct loaded_vmcs *loaded_vmcs);
>
> static inline struct vmcs *alloc_vmcs(bool shadow)
I think it'd be cleaner overall to take "enum vmcs_type" in alloc_vmcs().
Then the ternary operator goes away and the callers (all two of 'em) are
self-documenting. E.g.
diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index 79c7764c77b1..2c8a0a1386b1 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -4566,7 +4566,7 @@ static struct vmcs *alloc_shadow_vmcs(struct kvm_vcpu *vcpu)
WARN_ON(loaded_vmcs == &vmx->vmcs01 && loaded_vmcs->shadow_vmcs);
if (!loaded_vmcs->shadow_vmcs) {
- loaded_vmcs->shadow_vmcs = alloc_vmcs(true);
+ loaded_vmcs->shadow_vmcs = alloc_vmcs(SHADOW_VMCS_REGION);
if (loaded_vmcs->shadow_vmcs)
vmcs_clear(loaded_vmcs->shadow_vmcs);
}
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 5bdf6919de83..4634f6d7d55a 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -2605,7 +2605,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;
diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h
index 4c327030bb9c..a5eb92638ac2 100644
--- a/arch/x86/kvm/vmx/vmx.h
+++ b/arch/x86/kvm/vmx/vmx.h
@@ -502,10 +502,10 @@ 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 ? SHADOW_VMCS_REGION : VMCS_REGION,
- raw_smp_processor_id(), GFP_KERNEL_ACCOUNT);
+ return alloc_vmcs_cpu(type, raw_smp_processor_id(),
+ GFP_KERNEL_ACCOUNT);
}
u64 construct_eptp(struct kvm_vcpu *vcpu, unsigned long root_hpa);
> {
> - return alloc_vmcs_cpu(shadow, raw_smp_processor_id(),
> - GFP_KERNEL_ACCOUNT);
> + return alloc_vmcs_cpu(shadow ? SHADOW_VMCS_REGION : VMCS_REGION,
> + raw_smp_processor_id(), GFP_KERNEL_ACCOUNT);
> }
>
> u64 construct_eptp(struct kvm_vcpu *vcpu, unsigned long root_hpa);
> --
> 2.24.1
>
next prev parent reply other threads:[~2020-03-05 20:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-05 18:37 [PATCH v2 0/2] KVM: VMX: cleanup VMXON region allocation Vitaly Kuznetsov
2020-03-05 18:37 ` [PATCH v2 1/2] KVM: VMX: rename 'kvm_area' to 'vmxon_region' Vitaly Kuznetsov
2020-03-05 18:37 ` [PATCH v2 2/2] KVM: VMX: untangle VMXON revision_id setting when using eVMCS Vitaly Kuznetsov
2020-03-05 20:10 ` Sean Christopherson [this message]
2020-03-06 10:06 ` Vitaly Kuznetsov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200305201000.GQ11500@linux.intel.com \
--to=sean.j.christopherson@intel.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.