All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Zhenzhong Duan <zhenzhong.duan@intel.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	pbonzini@redhat.com, vkuznets@redhat.com, wanpengli@tencent.com,
	jmattson@google.com, joro@8bytes.org
Subject: Re: [PATCH] KVM: x86: Remove redundant vm_entry_controls_clearbit() call
Date: Thu, 10 Mar 2022 17:14:54 +0000	[thread overview]
Message-ID: <YioyDu+9VoGmTWlD@google.com> (raw)
In-Reply-To: <20220310111354.504565-1-zhenzhong.duan@intel.com>

On Thu, Mar 10, 2022, Zhenzhong Duan wrote:
> When emulating exit from long mode, EFER_LMA is cleared which lead to
> efer writing emulation, which will unset VM_ENTRY_IA32E_MODE control
> bit as requested by SDM. So no need to unset VM_ENTRY_IA32E_MODE again
> in exit_lmode() explicitly.
> 
> In fact benefited from shadow controls mechanism, this change doesn't
> eliminate vmread or vmwrite.
> 
> Opportunistically remove unnecessory assignment to uret MSR data field
> as vmx_setup_uret_msrs() will do the same thing.

This needs to be a separate patch, it's much more subtle than "xyz will do the
same thing".  update_transition_efer() doesn't unconditionally set uret->data,
which on the surface makes this look suspect, but it's safe because uret->data
is consumed if and only if uret->load_into_hardware is true, and it's (a) set to
false if uret->data isn't updated and (b) uret->data is guaranteed to be updated
before it's set to true.

> In case EFER isn't supported by hardware, long mode isn't supported,
> so this will no break.
>
> 
> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
> ---
>  arch/x86/kvm/vmx/vmx.c | 8 ++------
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index b730d799c26e..b04588dc7faa 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -2878,14 +2878,11 @@ int vmx_set_efer(struct kvm_vcpu *vcpu, u64 efer)
>  		return 0;
>  
>  	vcpu->arch.efer = efer;
> -	if (efer & EFER_LMA) {
> +	if (efer & EFER_LMA)
>  		vm_entry_controls_setbit(to_vmx(vcpu), VM_ENTRY_IA32E_MODE);
> -		msr->data = efer;
> -	} else {
> +	else
>  		vm_entry_controls_clearbit(to_vmx(vcpu), VM_ENTRY_IA32E_MODE);
>  
> -		msr->data = efer & ~EFER_LME;
> -	}

While you're doing opportunistic cleanups, drop the local "msr" and use "vmx"
directly instead of redoing to_vmx(), i.e. this

int vmx_set_efer(struct kvm_vcpu *vcpu, u64 efer)
{
	struct vcpu_vmx *vmx = to_vmx(vcpu);

	/* Nothing to do if hardware doesn't support EFER. */
	if (!vmx_find_uret_msr(vmx, MSR_EFER))
		return 0;

	vcpu->arch.efer = efer;
	if (efer & EFER_LMA)
		vm_entry_controls_setbit(vmx, VM_ENTRY_IA32E_MODE);
	else
		vm_entry_controls_clearbit(vmx, VM_ENTRY_IA32E_MODE);

	vmx_setup_uret_msrs(vmx);
	return 0;
}

      reply	other threads:[~2022-03-10 17:15 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-10 11:13 [PATCH] KVM: x86: Remove redundant vm_entry_controls_clearbit() call Zhenzhong Duan
2022-03-10 17:14 ` Sean Christopherson [this message]

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=YioyDu+9VoGmTWlD@google.com \
    --to=seanjc@google.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    --cc=zhenzhong.duan@intel.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.