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 v2 3/4] KVM: nVMX: Track whether changes in L0 require MSR bitmap for L2 to be rebuilt
Date: Fri, 8 Oct 2021 23:54:33 +0000 [thread overview]
Message-ID: <YWDaOf/10znebx5S@google.com> (raw)
In-Reply-To: <20211004161029.641155-4-vkuznets@redhat.com>
On Mon, Oct 04, 2021, Vitaly Kuznetsov wrote:
> Introduce a flag to keep track of whether MSR bitmap for L2 needs to be
> rebuilt due to changes in MSR bitmap for L1 or switching to a different
> L2. This information will be used for Enlightened MSR Bitmap feature for
> Hyper-V guests.
>
> Note, setting msr_bitmap_changed to 'true' from set_current_vmptr() is
> not really needed for Enlightened MSR Bitmap as the feature can only
> be used in conjunction with Enlightened VMCS but let's keep tracking
> information complete, it's cheap and in the future similar PV feature can
> easily be implemented for KVM on KVM too.
>
> No functional change intended.
>
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> ---
...
> void vmx_disable_intercept_for_msr(struct kvm_vcpu *vcpu, u32 msr, int type)
> diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h
> index 592217fd7d92..eb7a1697bec2 100644
> --- a/arch/x86/kvm/vmx/vmx.h
> +++ b/arch/x86/kvm/vmx/vmx.h
> @@ -148,6 +148,12 @@ struct nested_vmx {
> bool need_vmcs12_to_shadow_sync;
> bool dirty_vmcs12;
>
> + /*
> + * Indicates whether MSR bitmap for L2 needs to be rebuilt due to
> + * changes in MSR bitmap for L1 or switching to a different L2.
> + */
> + bool msr_bitmap_changed;
This is misleading, and arguably wrong. It's only accurate when used in conjuction
with a paravirt L1 that states if a VMCS has a dirty MSR bitmap. E.g. this flag
will be wrong if L1 changes the address of the bitmap in the VMCS, and it's
obviously wrong if L1 changes the MSR bitmap itself.
The changelog kind of covers that, but those details will be completely lost to
readers of the code.
Would it be illegal from KVM to simply clear the CLEAN bit in the eVMCS at the
appropriate points?
> +
> /*
> * Indicates lazily loaded guest state has not yet been decached from
> * vmcs02.
> --
> 2.31.1
>
next prev parent reply other threads:[~2021-10-08 23:54 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-04 16:10 [PATCH v2 0/4] KVM: nVMX: Enlightened MSR Bitmap feature for Hyper-V on KVM Vitaly Kuznetsov
2021-10-04 16:10 ` [PATCH v2 1/4] KVM: nVMX: Don't use Enlightened MSR Bitmap for L3 Vitaly Kuznetsov
2021-10-04 16:10 ` [PATCH v2 2/4] KVM: VMX: Introduce vmx_msr_bitmap_l01_changed() helper Vitaly Kuznetsov
2021-10-04 16:10 ` [PATCH v2 3/4] KVM: nVMX: Track whether changes in L0 require MSR bitmap for L2 to be rebuilt Vitaly Kuznetsov
2021-10-08 23:54 ` Sean Christopherson [this message]
2021-10-11 15:13 ` Vitaly Kuznetsov
2021-10-11 16:44 ` Paolo Bonzini
2021-10-04 16:10 ` [PATCH v2 4/4] KVM: nVMX: Implement Enlightened MSR Bitmap feature 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=YWDaOf/10znebx5S@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox