All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Xiaoyao Li <xiaoyao.li@intel.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Paolo Bonzini <pbonzini@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>
Subject: Re: [PATCH 1/2] kvm: vmx: Use basic exit reason to check if it's the specific VM EXIT
Date: Mon, 24 Feb 2020 22:13:17 -0800	[thread overview]
Message-ID: <20200225061317.GV29865@linux.intel.com> (raw)
In-Reply-To: <50134028-ef7a-46c6-7602-095c47406ed7@intel.com>

On Tue, Feb 25, 2020 at 08:13:15AM +0800, Xiaoyao Li wrote:
> On 2/25/2020 12:17 AM, Sean Christopherson wrote:
> >On Mon, Feb 24, 2020 at 02:04:46PM +0100, Vitaly Kuznetsov wrote:
> >>Xiaoyao Li <xiaoyao.li@intel.com> writes:
> >>
> >>>On 2/24/2020 6:16 PM, Vitaly Kuznetsov wrote:
> >>>>Xiaoyao Li <xiaoyao.li@intel.com> writes:
> >>>>
> >>>Here variable basic_exit_reason is added for the cases where only basic
> >>>exit reason number is needed.
> >>>
> >>
> >>Can we do the other way around, i.e. introduce 'extended_exit_reason'
> >>and use it where all 32 bits are needed? I'm fine with the change, just
> >>trying to minimize the (unneeded) code churn.
> >
> >100% agree.  Even better than adding a second field to vcpu_vmx would be
> >to make it a union, though we'd probably want to call it something like
> >full_exit_reason in that case.  That should give us compile-time checks on
> >exit_reason, e.g. if we try to query one of the upper bits using a u16, e.g.
> 
> I have thought about union, but it seems
> 
> union {
> 	u16 exit_reason;
> 	u32 full_exit_reason;
> }
> 
> is not a good name. Since there are many codes in vmx.c and nested.c assume
> that exit_reason stands for 32-bit EXIT REASON vmcs field as well as
> evmcs->vm_exit_reason and vmcs12->vm_exit_reason. Do we really want to also
> rename them to full_exit_reason?

It's actually the opposite, almost all of the VMX code assumes exit_reason
holds only the basic exit reason, i.e. a 16-bit value.  For example, SGX
adds a modifier flag to denote a VM-Exit was from enclave mode, and that
bit needs to be stripped from exit_reason, otherwise all the checks like
"if (exit_reason == blah_blah_blah)" fail.  

Making exit_reason a 16-bit alias of the full/extended exit_reason neatly
sidesteps that issue.  And it is an issue that has caused actual problems
in the past, e.g. see commit beb8d93b3e42 ("KVM: VMX: Fix handling of #MC
that occurs during VM-Entry").  Coincidentally, that commit also removes a
local "u16 basic_exit_reason" :-).

Except for one mistake, the pseudo-patch below is the entirety of required
changes.  Most (all?) of the functions that take "u32 exit_reason" can (and
should) continue to take a u32.

As for the name, I strongly prefer keeping the exit_reason name for the
basic exit reason.  The vast majority of VM-Exits do not have modifiers
set, i.e. "basic exit reason" == vmcs.EXIT_REASON for nearly all normal
usage.  This holds true in every form of communication, e.g. when discussing
VM-Exit reasons, it's never qualified with "basic", it's simply the exit
reason.  IMO the code is better off following the colloquial usage of "exit
reason".  A simple comment above the union would suffice to clear up any
confusion with respect to the SDM.

> Maybe we name it
> 
> union {
> 	u16 basic_exit_reason;
> 	u32 exit_reason;
> }
> 
> as what SDM defines?
> 
> >--- a/arch/x86/kvm/vmx/vmx.c
> >+++ b/arch/x86/kvm/vmx/vmx.c
> >@@ -5818,7 +5818,7 @@ static int vmx_handle_exit(struct kvm_vcpu *vcpu,
> >         if (is_guest_mode(vcpu) && nested_vmx_exit_reflected(vcpu, exit_reason))
> >                 return nested_vmx_reflect_vmexit(vcpu, exit_reason);
> >
> >-       if (exit_reason & VMX_EXIT_REASONS_FAILED_VMENTRY) {
> >+       if (vmx->full_exit_reason & VMX_EXIT_REASONS_FAILED_VMENTRY) {

If we do go the union route, this snippet of code is insufficient, the
full/extended exit reason needs to be snapshotted early for use in the
tracepoint and in fail_entry.hardware_entry_failure_reason.

> >                 dump_vmcs();
> >                 vcpu->run->exit_reason = KVM_EXIT_FAIL_ENTRY;
> >                 vcpu->run->fail_entry.hardware_entry_failure_reason
> >@@ -6620,11 +6620,12 @@ static void vmx_vcpu_run(struct kvm_vcpu *vcpu)
> >         vmx->nested.nested_run_pending = 0;
> >         vmx->idt_vectoring_info = 0;
> >
> >-       vmx->exit_reason = vmx->fail ? 0xdead : vmcs_read32(VM_EXIT_REASON);
> >-       if ((u16)vmx->exit_reason == EXIT_REASON_MCE_DURING_VMENTRY)
> >+       vmx->full_exit_reason = vmx->fail ? 0xdead : vmcs_read32(VM_EXIT_REASON);
> >+       if (vmx->exit_reason == EXIT_REASON_MCE_DURING_VMENTRY)
> >                 kvm_machine_check();
> >
> >-       if (vmx->fail || (vmx->exit_reason & VMX_EXIT_REASONS_FAILED_VMENTRY))
> >+       if (vmx->fail ||
> >+           (vmx->full_exit_reason & VMX_EXIT_REASONS_FAILED_VMENTRY))
> >                 return;
> >
> >         vmx->loaded_vmcs->launched = 1;
> >diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h
> >index 7f42cf3dcd70..60c09640ea59 100644
> >--- a/arch/x86/kvm/vmx/vmx.h
> >+++ b/arch/x86/kvm/vmx/vmx.h
> >@@ -260,7 +260,10 @@ struct vcpu_vmx {
> >         int vpid;
> >         bool emulation_required;
> >
> >-       u32 exit_reason;
> >+       union {
> >+               u16 exit_reason;
> >+               u32 full_exit_reason;
> >+       }
> >
> >         /* Posted interrupt descriptor */
> >         struct pi_desc pi_desc;
> >
> >
> >
> >
> >
> >>-- 
> >>Vitaly
> >>
> 

  reply	other threads:[~2020-02-25  6:13 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-24  2:07 [PATCH 0/2] KVM: VMX: Use basic exit reason for cheking and indexing Xiaoyao Li
2020-02-24  2:07 ` [PATCH 1/2] kvm: vmx: Use basic exit reason to check if it's the specific VM EXIT Xiaoyao Li
2020-02-24 10:16   ` Vitaly Kuznetsov
2020-02-24 12:01     ` Xiaoyao Li
2020-02-24 13:04       ` Vitaly Kuznetsov
2020-02-24 16:17         ` Sean Christopherson
2020-02-25  0:13           ` Xiaoyao Li
2020-02-25  6:13             ` Sean Christopherson [this message]
2020-02-25  6:41               ` Xiaoyao Li
2020-02-26 23:59                 ` Sean Christopherson
2020-02-27  8:35                   ` Xiaoyao Li
2020-02-27 23:57                     ` Sean Christopherson
2020-02-25  0:27       ` Krish Sadhukhan
2020-02-25 13:11         ` Vitaly Kuznetsov
2020-02-25 18:28           ` Krish Sadhukhan
2020-02-24  2:07 ` [PATCH 2/2] kvm: nvmx: Use basic(exit_reason) when checking specific EXIT_REASON Xiaoyao Li

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=20200225061317.GV29865@linux.intel.com \
    --to=sean.j.christopherson@intel.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=xiaoyao.li@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.