This is a stopgap solution until the toolstack side of initialisation can be
sorted out, but it does result in the nvmx_vcpu_in_vmx() predicate working
correctly even when nested virt hasn't been enabled for the domain.
Update nvmx_handle_vmx_insn() to include the in-vmx mode check (for all
instructions other than VMXON) to complete the set of #UD checks.
In addition, sanity check that the nested vmexit handler has worked correctly,
and that we are only providing emulation of the VT-x instructions to L1
guests.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Sergey Dyasli <sergey.dyasli@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
INIT_LIST_HEAD(&v->arch.hvm.vmx.pi_blocking.list);
+ vcpu_2_nvmx(v).vmxon_region_pa = INVALID_PADDR;
+
if ( (rc = vmx_create_vmcs(v)) != 0 )
{
dprintk(XENLOG_WARNING,
if ( !(curr->arch.hvm.guest_cr[4] & X86_CR4_VMXE) ||
!nestedhvm_enabled(curr->domain) ||
- (vmx_guest_x86_mode(curr) < (hvm_long_mode_active(curr) ? 8 : 2)) )
+ (vmx_guest_x86_mode(curr) < (hvm_long_mode_active(curr) ? 8 : 2)) ||
+ (exit_reason != EXIT_REASON_VMXON && !nvmx_vcpu_in_vmx(curr)) )
{
hvm_inject_hw_exception(TRAP_invalid_op, X86_EVENT_NO_EC);
return X86EMUL_EXCEPTION;
return X86EMUL_EXCEPTION;
}
+ if ( nestedhvm_vcpu_in_guestmode(curr) )
+ {
+ /* Should have been handled by nvmx_n2_vmexit_handler()... */
+ ASSERT_UNREACHABLE();
+ domain_crash(curr->domain);
+ return X86EMUL_UNHANDLEABLE;
+ }
+
switch ( exit_reason )
{
case EXIT_REASON_VMXOFF: