Separate Hypervisor Core from OS Layer. Don't touch IRQL in Hypervisor. Separate Load vs Unload callback. Misc. portability fixes.

Create a layer of OS-specific functions to handle the various
requirements around memory allocation, context save/restore,
entrypoint/unloadpoint, and multi-CPU execution and topology
information. SimpleVisor no longer uses NT-specific functions (some
structures and types still remain).
Additionally, the hypervisor should not know that "NT" is running
underneath, so it has no business touching the IRQL. As we won't call
Windows functions, and as interrupts are disabled, this doesn't 'change'
anything and is correct.
Don't use the same callback for load and unload. We can make unload its
own callback now, as we've separated out the DPC-specific logic. This
makes the load callback cleaner as well.
Remove NT_ASSERTS which don't work anyway, and use portable
definitions/types when possible (more to do here).
Return the failed CPU and status in all cases during load. Sometimes
this wasn't done before.

1 files changed, 1 insertions, 21 deletions

diff --git a/shvvmxhv.c b/shvvmxhv.c
index 6a54fda..879928b 100644
--- a/shvvmxhv.c
+++ b/shvvmxhv.c
@@ -189,7 +189,6 @@ ShvVmxHandleExit (
         ShvVmxHandleVmx(VpState);
         break;
     default:
-        NT_ASSERT(FALSE);
         break;
     }
 
@@ -203,7 +202,6 @@ ShvVmxHandleExit (
 }
 
 DECLSPEC_NORETURN
-EXTERN_C
 VOID
 ShvVmxEntryHandler (
     _In_ PCONTEXT Context
@@ -213,19 +211,6 @@ ShvVmxEntryHandler (
     PSHV_VP_DATA vpData;
 
     //
-    // Because we run with interrupts disabled during the entire hypervisor's
-    // exit handling, raise the IRQL to HIGH_LEVEL which matches the reality of
-    // the situation. This will block IPIs and the clock interrupt timer, which
-    // means that it's critical to spend as little time here as possible. You
-    // can expect CLOCK_WATCHDOG_TIMEOUT bugchecks to happen otherwise. If you
-    // chose to enable interrupts note that this will result in further crashes
-    // as we are not on a correct OS stack, and you will be hitting crashes if
-    // RtlpCheckStackLimits is ever called, or if PatchGuard validates the RSP
-    // value.
-    //
-    KeRaiseIrql(HIGH_LEVEL, &guestContext.GuestIrql);
-
-    //
     // Because we had to use RCX when calling RtlCaptureContext, its true value
     // was actually pushed on the stack right before the call. Go dig into the
     // stack to find it, and overwrite the bogus value that's there now.
@@ -326,17 +311,12 @@ ShvVmxEntryHandler (
     }
 
     //
-    // Restore the IRQL back to the original level
-    //
-    KeLowerIrql(guestContext.GuestIrql);
-
-    //
     // Restore the context to either ShvVmxResume, in which case the CPU's VMX
     // facility will do the "true" return back to the VM (but without restoring
     // GPRs, which is why we must do it here), or to the original guest's RIP,
     // which we use in case an exit was requested. In this case VMX must now be
     // off, and this will look like a longjmp to the original stack and RIP.
     //
-    RtlRestoreContext(Context, NULL);
+    ShvOsRestoreContext(Context);
 }