[Xen-devel] [PATCH XTF] nested-vmx: exceptions take priority over VMFail*

["Jan Beulich" <JBeulich@xxxxxxxx>]

The way the instruction invocations are coded, it is compiler version
dependent whether things work: With old gcc, fail_{,in}valid will not
get touched and hence remain at their initial values, while with newer
gcc evaluation of the status flags occurs outside of the asm(), i.e.
also when an exception was received (in which case EFLAGS didn't change
from its value before the faulting instruction).

Since it is more logical anyway to check for a possible exception first,
do so uniformly instead of trying to fiddle with the asm() in some way.

Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>

--- a/tests/nested-vmx/util.c
+++ b/tests/nested-vmx/util.c
@@ -90,12 +90,14 @@ exinfo_t stub_vmxon(uint64_t paddr)
                   : [paddr] "m" (paddr),
                     "X" (ex_record_fault_edi));
 
-    if ( fail_invalid )
+    if ( ex )
+        return ex;
+    else if ( fail_invalid )
         return VMERR_INVALID;
     else if ( fail_valid )
         return get_vmx_insn_err();
     else
-        return ex;
+        return VMERR_SUCCESS;
 }
 
 exinfo_t stub_vmptrld(uint64_t paddr)
@@ -114,12 +116,14 @@ exinfo_t stub_vmptrld(uint64_t paddr)
                   : [paddr] "m" (paddr),
                     "X" (ex_record_fault_edi));
 
-    if ( fail_invalid )
+    if ( ex )
+        return ex;
+    else if ( fail_invalid )
         return VMERR_INVALID;
     else if ( fail_valid )
         return get_vmx_insn_err();
     else
-        return ex;
+        return VMERR_SUCCESS;
 }
 
 exinfo_t __user_text stub_vmxon_user(uint64_t paddr)
@@ -138,12 +142,14 @@ exinfo_t __user_text stub_vmxon_user(uin
                   : [paddr] "m" (paddr),
                     "X" (ex_record_fault_edi));
 
-    if ( fail_invalid )
+    if ( ex )
+        return ex;
+    else if ( fail_invalid )
         return VMERR_INVALID;
     else if ( fail_valid )
         return get_vmx_insn_err();
     else
-        return ex;
+        return VMERR_SUCCESS;
 }
 
 /*





_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel