All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Krish Sadhukhan <krish.sadhukhan@oracle.com>
Cc: kvm@vger.kernel.org, rkrcmar@redhat.com, pbonzini@redhat.com,
	jmattson@google.com
Subject: Re: [PATCH 3/4] kvm-unit-test: nVMX: __enter_guest() should not set "launched" state when VM-entry fails
Date: Fri, 13 Sep 2019 14:06:45 -0700	[thread overview]
Message-ID: <20190913210645.GA14482@linux.intel.com> (raw)
In-Reply-To: <a2268863-e554-4547-5196-3509bda3ace3@oracle.com>

On Fri, Sep 13, 2019 at 01:37:55PM -0700, Krish Sadhukhan wrote:
> 
> On 9/4/19 8:42 AM, Sean Christopherson wrote:
> >On Thu, Aug 29, 2019 at 04:56:34PM -0400, Krish Sadhukhan wrote:
> >>Bit# 31 in VM-exit reason is set by hardware in both cases of early VM-entry
> >>failures and VM-entry failures due to invalid guest state.
> >This is incorrect, VMCS.EXIT_REASON is not written on a VM-Fail.  If the
> >tests are passing, you're probably consuming a stale EXIT_REASON.
> 
> In vmx_vcpu_run(),
> 
>         if (vmx->fail || (vmx->exit_reason &
> VMX_EXIT_REASONS_FAILED_VMENTRY))
>                 return;
> 
>         vmx->loaded_vmcs->launched = 1;
> 
> we return without setting "launched" whenever bit# 31 is set in Exit Reason.
> If VM-entry fails due to invalid guest state or due to errors in VM-entry
> MSR-loading area, bit#31 is set.  As a result, L2 is not in "launched" state
> when we return to L1.  Tests that want to VMRESUME L2 after fixing the bad
> guest state or the bad MSR-loading area, fail with VM-Instruction Error 5,
> 
>         "Early vmresume failure: error number is 5. See Intel 30.4."

Yes, a VMCS isn't marked launched if it generates a VM-Exit due to a
failed consistency check.  But as that code shows, a failed consistency
check results in said VM-Exit *or* a VM-Fail.  Cosnsitency checks that
fail early, i.e. before loading guest state, generate VM-Fail, any check
that fails after the CPU has started loading guest state manifests as a
VM-Exit.  VMCS.EXIT_REASON isn't touched in the VM-Fail case.

E.g. in CHECKS ON VMX CONTROLS AND HOST-STATE AREA, the SDM states:

  VM entry fails if any of these checks fail.  When such failures occur,
  control is passed to the next instruction, RFLAGS.ZF is set to 1 to
  indicate the failure, and the VM-instruction error field is loaded with
  an error number that indicates whether the failure was due to the
  controls or the host-state area (see Chapter 30).

  reply	other threads:[~2019-09-13 21:06 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-29 20:56 [PATCH 0/4] KVM: nVMX: Check GUEST_DEBUGCTL and GUEST_DR7 on vmentry of nested guests Krish Sadhukhan
2019-08-29 20:56 ` [PATCH 1/4] KVM: nVMX: Check GUEST_DEBUGCTL " Krish Sadhukhan
2019-08-29 22:12   ` Jim Mattson
2019-08-30 23:26     ` Krish Sadhukhan
2019-09-01 23:55       ` Jim Mattson
2019-08-29 20:56 ` [PATCH 2/4] KVM: nVMX: Check GUEST_DR7 " Krish Sadhukhan
2019-08-29 22:26   ` Jim Mattson
2019-08-30 23:07     ` Krish Sadhukhan
2019-08-30 23:15       ` Jim Mattson
2019-09-02  0:33         ` Jim Mattson
     [not found]           ` <e229bea2-acb2-e268-6281-d8e467c3282e@oracle.com>
2019-09-04 16:44             ` Jim Mattson
2019-09-04 16:58               ` Sean Christopherson
2019-09-04 18:05               ` Krish Sadhukhan
2019-09-04 18:20                 ` Jim Mattson
2019-09-09  4:11                   ` Krish Sadhukhan
2019-09-09 15:56                     ` Jim Mattson
2019-09-04 17:14           ` Sean Christopherson
2019-12-20 23:45         ` Jim Mattson
2019-12-21  0:27   ` Jim Mattson
2019-08-29 20:56 ` [PATCH 3/4] kvm-unit-test: nVMX: __enter_guest() should not set "launched" state when VM-entry fails Krish Sadhukhan
2019-09-04 15:42   ` Sean Christopherson
2019-09-13 20:37     ` Krish Sadhukhan
2019-09-13 21:06       ` Sean Christopherson [this message]
2019-09-16 19:12         ` Krish Sadhukhan
2019-08-29 20:56 ` [PATCH 4/4] kvm-unit-test: nVMX: Check GUEST_DEBUGCTL and GUEST_DR7 on vmentry of nested guests Krish Sadhukhan
2019-08-29 23:17   ` Jim Mattson
2019-08-30  1:12     ` Nadav Amit

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=20190913210645.GA14482@linux.intel.com \
    --to=sean.j.christopherson@intel.com \
    --cc=jmattson@google.com \
    --cc=krish.sadhukhan@oracle.com \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.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.