From: Sean Christopherson <seanjc@google.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>,
Maxim Levitsky <mlevitsk@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 4/4] KVM: nVMX: Implement Enlightened MSR Bitmap feature
Date: Fri, 5 Nov 2021 01:09:53 +0000 [thread overview]
Message-ID: <YYSEYY4h6NN7FGbR@google.com> (raw)
In-Reply-To: <20211013142258.1738415-5-vkuznets@redhat.com>
On Wed, Oct 13, 2021, Vitaly Kuznetsov wrote:
> Updating MSR bitmap for L2 is not cheap and rearly needed. TLFS for Hyper-V
> offers 'Enlightened MSR Bitmap' feature which allows L1 hypervisor to
> inform L0 when it changes MSR bitmap, this eliminates the need to examine
> L1's MSR bitmap for L2 every time when 'real' MSR bitmap for L2 gets
> constructed.
>
> Use 'vmx->nested.msr_bitmap_changed' flag to implement the feature.
>
> Note, KVM already uses 'Enlightened MSR bitmap' feature when it runs as a
> nested hypervisor on top of Hyper-V. The newly introduced feature is going
> to be used by Hyper-V guests on KVM.
>
> When the feature is enabled for Win10+WSL2, it shaves off around 700 CPU
> cycles from a nested vmexit cost (tight cpuid loop test).
>
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> ---
> arch/x86/kvm/hyperv.c | 2 ++
> arch/x86/kvm/vmx/nested.c | 20 ++++++++++++++++++--
> 2 files changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
> index 6f11cda2bfa4..a00de1dbec57 100644
> --- a/arch/x86/kvm/hyperv.c
> +++ b/arch/x86/kvm/hyperv.c
> @@ -2516,6 +2516,8 @@ int kvm_get_hv_cpuid(struct kvm_vcpu *vcpu, struct kvm_cpuid2 *cpuid,
>
> case HYPERV_CPUID_NESTED_FEATURES:
> ent->eax = evmcs_ver;
> + if (evmcs_ver)
> + ent->eax |= HV_X64_NESTED_MSR_BITMAP;
>
> break;
>
> diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
> index bf4fa63ed371..7cd0c20d4557 100644
> --- a/arch/x86/kvm/vmx/nested.c
> +++ b/arch/x86/kvm/vmx/nested.c
> @@ -608,15 +608,30 @@ static inline bool nested_vmx_prepare_msr_bitmap(struct kvm_vcpu *vcpu,
> struct vmcs12 *vmcs12)
> {
> int msr;
> + struct vcpu_vmx *vmx = to_vmx(vcpu);
> unsigned long *msr_bitmap_l1;
> - unsigned long *msr_bitmap_l0 = to_vmx(vcpu)->nested.vmcs02.msr_bitmap;
> - struct kvm_host_map *map = &to_vmx(vcpu)->nested.msr_bitmap_map;
> + unsigned long *msr_bitmap_l0 = vmx->nested.vmcs02.msr_bitmap;
> + struct hv_enlightened_vmcs *evmcs = vmx->nested.hv_evmcs;
> + struct kvm_host_map *map = &vmx->nested.msr_bitmap_map;
That reminds me, can my nested bitmap fixes get merged? Superficial conflicts,
but still conflicts that I'd rather not have to resolve :-)
https://lkml.kernel.org/r/20210924204907.1111817-1-seanjc@google.com
>
> /* Nothing to do if the MSR bitmap is not in use. */
> if (!cpu_has_vmx_msr_bitmap() ||
> !nested_cpu_has(vmcs12, CPU_BASED_USE_MSR_BITMAPS))
> return false;
>
> + /*
> + * MSR bitmap update can be skipped when:
> + * - MSR bitmap for L1 hasn't changed.
> + * - Nested hypervisor (L1) is attempting to launch the same L2 as
> + * before.
> + * - Nested hypervisor (L1) has enabled 'Enlightened MSR Bitmap' feature
> + * and tells KVM (L0) there were no changes in MSR bitmap for L2.
> + */
> + if (!vmx->nested.msr_bitmap_force_recalc && evmcs &&
> + evmcs->hv_enlightenments_control.msr_bitmap &&
> + evmcs->hv_clean_fields & HV_VMX_ENLIGHTENED_CLEAN_FIELD_MSR_BITMAP)
> + goto out_clear_msr_bitmap_force_recalc;
Huh? Why clear it, it's already clear. Any reason not to simply return true?
> +
> if (kvm_vcpu_map(vcpu, gpa_to_gfn(vmcs12->msr_bitmap), map))
> return false;
>
> @@ -700,6 +715,7 @@ static inline bool nested_vmx_prepare_msr_bitmap(struct kvm_vcpu *vcpu,
>
> kvm_vcpu_unmap(vcpu, &to_vmx(vcpu)->nested.msr_bitmap_map, false);
>
> +out_clear_msr_bitmap_force_recalc:
> vmx->nested.msr_bitmap_force_recalc = false;
>
> return true;
> --
> 2.31.1
>
next prev parent reply other threads:[~2021-11-05 1:10 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-13 14:22 [PATCH v3 0/4] KVM: nVMX: Enlightened MSR Bitmap feature for Hyper-V on KVM Vitaly Kuznetsov
2021-10-13 14:22 ` [PATCH v3 1/4] KVM: nVMX: Don't use Enlightened MSR Bitmap for L3 Vitaly Kuznetsov
2021-11-05 0:52 ` Sean Christopherson
2021-11-05 12:03 ` Vitaly Kuznetsov
2021-11-05 15:38 ` Maxim Levitsky
2021-11-05 15:39 ` Maxim Levitsky
2021-10-13 14:22 ` [PATCH v3 2/4] KVM: VMX: Introduce vmx_msr_bitmap_l01_changed() helper Vitaly Kuznetsov
2021-11-05 1:00 ` Sean Christopherson
2021-10-13 14:22 ` [PATCH v3 3/4] KVM: nVMX: Track whether changes in L0 require MSR bitmap for L2 to be rebuilt Vitaly Kuznetsov
2021-11-05 1:05 ` Sean Christopherson
2021-11-05 12:06 ` Vitaly Kuznetsov
2021-11-05 14:28 ` Sean Christopherson
2021-10-13 14:22 ` [PATCH v3 4/4] KVM: nVMX: Implement Enlightened MSR Bitmap feature Vitaly Kuznetsov
2021-11-05 1:09 ` Sean Christopherson [this message]
2021-11-05 12:08 ` Vitaly Kuznetsov
2021-11-03 15:13 ` [PATCH v3 0/4] KVM: nVMX: Enlightened MSR Bitmap feature for Hyper-V on KVM 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=YYSEYY4h6NN7FGbR@google.com \
--to=seanjc@google.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mlevitsk@redhat.com \
--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.