lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 25 Jan 2022 16:57:05 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Vitaly Kuznetsov <vkuznets@...hat.com>, kvm@...r.kernel.org
Cc:     Sean Christopherson <seanjc@...gle.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Maxim Levitsky <mlevitsk@...hat.com>,
        Vineeth Pillai <viremana@...ux.microsoft.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/5] KVM: SVM: Drop stale comment from
 svm_hv_vmcb_dirty_nested_enlightenments()

On 12/20/21 16:21, Vitaly Kuznetsov wrote:
> Commit 3fa5e8fd0a0e4 ("KVM: SVM: delay svm_vcpu_init_msrpm after
> svm->vmcb is initialized") re-arranged svm_vcpu_init_msrpm() call in
> svm_create_vcpu() making the comment about vmcb being NULL
> obsolete. Drop it.
> 
> While on it, drop superfluous vmcb_is_clean() check: vmcb_mark_dirty()
> is a bit flip, an extra check is unlikely to bring any performance gain.
> Drop now-unneeded vmcb_is_clean() helper as well.
> 
> Fixes: 3fa5e8fd0a0e4 ("KVM: SVM: delay svm_vcpu_init_msrpm after svm->vmcb is initialized")
> Signed-off-by: Vitaly Kuznetsov <vkuznets@...hat.com>

Queued, but with subject changed to "KVM: SVM: clean up beginning of 
svm_hv_vmcb_dirty_nested_enlightenments()".

Paolo

>   arch/x86/kvm/svm/svm.h          | 5 -----
>   arch/x86/kvm/svm/svm_onhyperv.h | 9 +--------
>   2 files changed, 1 insertion(+), 13 deletions(-)
> 
> diff --git a/arch/x86/kvm/svm/svm.h b/arch/x86/kvm/svm/svm.h
> index daa8ca84afcc..5d197aae3a19 100644
> --- a/arch/x86/kvm/svm/svm.h
> +++ b/arch/x86/kvm/svm/svm.h
> @@ -305,11 +305,6 @@ static inline void vmcb_mark_all_clean(struct vmcb *vmcb)
>   			       & ~VMCB_ALWAYS_DIRTY_MASK;
>   }
>   
> -static inline bool vmcb_is_clean(struct vmcb *vmcb, int bit)
> -{
> -	return (vmcb->control.clean & (1 << bit));
> -}
> -
>   static inline void vmcb_mark_dirty(struct vmcb *vmcb, int bit)
>   {
>   	vmcb->control.clean &= ~(1 << bit);
> diff --git a/arch/x86/kvm/svm/svm_onhyperv.h b/arch/x86/kvm/svm/svm_onhyperv.h
> index c53b8bf8d013..cdbcfc63d171 100644
> --- a/arch/x86/kvm/svm/svm_onhyperv.h
> +++ b/arch/x86/kvm/svm/svm_onhyperv.h
> @@ -83,14 +83,7 @@ static inline void svm_hv_vmcb_dirty_nested_enlightenments(
>   	struct hv_enlightenments *hve =
>   		(struct hv_enlightenments *)vmcb->control.reserved_sw;
>   
> -	/*
> -	 * vmcb can be NULL if called during early vcpu init.
> -	 * And its okay not to mark vmcb dirty during vcpu init
> -	 * as we mark it dirty unconditionally towards end of vcpu
> -	 * init phase.
> -	 */
> -	if (vmcb_is_clean(vmcb, VMCB_HV_NESTED_ENLIGHTENMENTS) &&
> -	    hve->hv_enlightenments_control.msr_bitmap)
> +	if (hve->hv_enlightenments_control.msr_bitmap)
>   		vmcb_mark_dirty(vmcb, VMCB_HV_NESTED_ENLIGHTENMENTS);
>   }
>   

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ