linux-kernel - Re: [PATCH v3] KVM: VMX: Remove redundant handling of bus lock vmexit

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:   Fri, 15 Oct 2021 14:45:14 +0000
From:   Sean Christopherson <seanjc@...gle.com>
To:     Hao Xiang <hao.xiang@...ux.alibaba.com>
Cc:     kvm@...r.kernel.org, shannon.zhao@...ux.alibaba.com,
        pbonzini@...hat.com, xiaoyao.li@...el.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] KVM: VMX: Remove redundant handling of bus lock vmexit

On Fri, Oct 15, 2021, Hao Xiang wrote:
> Hardware may or may not set exit_reason.bus_lock_detected on BUS_LOCK
> VM-Exits. Dealing with KVM_RUN_X86_BUS_LOCK in handle_bus_lock_vmexit
> could be redundant when exit_reason.basic is EXIT_REASON_BUS_LOCK.
> 
> We can remove redundant handling of bus lock vmexit. Unconditionally Set
> exit_reason.bus_lock_detected in handle_bus_lock_vmexit(), and deal with
> KVM_RUN_X86_BUS_LOCK only in vmx_handle_exit().
> 
> Suggested-by: Xiaoyao Li <xiaoyao.li@...el.com>

Code review feedback generally doesn't warrant a Suggested-by.  The intent of
Suggested-by is to give credit to the idea/approach of a patch, so unless the
review feedback suggests a completely different, noting the input in the delta
(as you did below) is sufficient.  And then that way you don't need to juggle
the Suggested-by vs Co-developed-by for me.

> Co-developed-by: Sean Christopherson <seanjc@...gle.com>
> Signed-off-by: Sean Christopherson <seanjc@...gle.com>

> Signed-off-by: Hao Xiang <hao.xiang@...ux.alibaba.com>
> ---
> v1 -> v2: a little modifications of comments
> v2 -> v3: addressed the review comments
> 
>  arch/x86/kvm/vmx/vmx.c | 15 +++++++++------
>  1 file changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index 116b089..7fb2a3a 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -5562,9 +5562,13 @@ static int handle_encls(struct kvm_vcpu *vcpu)
>  
>  static int handle_bus_lock_vmexit(struct kvm_vcpu *vcpu)
>  {
> -	vcpu->run->exit_reason = KVM_EXIT_X86_BUS_LOCK;
> -	vcpu->run->flags |= KVM_RUN_X86_BUS_LOCK;
> -	return 0;
> +	/*
> +	 * Hardware may or may not set the BUS_LOCK_DETECTED flag on BUS_LOCK
> +	 * VM-Exits. Unconditionally set the flag here and leave the handling to
> +	 * vmx_handle_exit().

+1 for "Unconditionally" instead of "Force".  Any objection to rewording the
second half slightly?

	/*
	 * Hardware may or may not set the BUS_LOCK_DETECTED flag on BUS_LOCK
	 * VM-Exits. Unconditionally set the flag here and let vmx_handle_exit()
	 * handle all flavors of bus-lock exits.
	 */

Not a big deal in this case, but in the future please give reviewers a chance to
respond and wait for discussion to settle before sending a new version, e.g. I
would happily have replied to Xiaoyao's suggestion in v2.