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).
