Index: /trunk/src/VBox/VMM/VMMR0/HMVMXR0.cpp
===================================================================
--- /trunk/src/VBox/VMM/VMMR0/HMVMXR0.cpp	(revision 50425)
+++ /trunk/src/VBox/VMM/VMMR0/HMVMXR0.cpp	(revision 50426)
@@ -2750,5 +2750,5 @@
         { \
             uint32_t uAttr = ASMGetSegAttr((selValue)); \
-            fValidSelector = RT_BOOL(uAttr != ~0U && (uAttr & X86_DESC_P)); \
+            fValidSelector = RT_BOOL(uAttr != UINT32_MAX && (uAttr & X86_DESC_P)); \
         } \
         if (fValidSelector) \
@@ -2774,4 +2774,12 @@
     NOREF(pVM);
     int rc = VERR_INTERNAL_ERROR_5;
+
+    /*
+     * Quick fix for regression #7240.  Restore the host state if we've messed
+     * it up already, otherwise all we'll get it all wrong below!
+     */
+    if (   (pVCpu->hm.s.vmx.fRestoreHostFlags & VMX_RESTORE_HOST_REQUIRED)
+        && (pVCpu->hm.s.vmx.fRestoreHostFlags & ~VMX_RESTORE_HOST_REQUIRED))
+        VMXRestoreHostState(pVCpu->hm.s.vmx.fRestoreHostFlags, &pVCpu->hm.s.vmx.RestoreHost);
 
     /*
@@ -2899,9 +2907,16 @@
 
         /*
-         * IDT limit is practically 0xfff. Therefore if the host has the limit as 0xfff, VT-x bloating the limit to 0xffff
-         * is not a problem as it's not possible to get at them anyway. See Intel spec. 6.14.1 "64-Bit Mode IDT" and
-         * Intel spec. 6.2 "Exception and Interrupt Vectors".
+         * IDT limit is effectively capped at 0xfff. (See Intel spec. 6.14.1 "64-Bit Mode IDT"
+         * and Intel spec. 6.2 "Exception and Interrupt Vectors".)  Therefore if the host has the limit as 0xfff, VT-x
+         * bloating the limit to 0xffff shouldn't cause any different CPU behavior.  However, several hosts either insists
+         * on 0xfff being the limit (Windows Patch Guard) or uses the limit for other purposes (darwin puts the CPU ID in there
+         * but botches sidt alignment in at least one consumer).  So, we're only allowing IDTR.LIMIT to be left at 0xffff on
+         * hosts where we are pretty sure it won't cause trouble.
          */
-        if (Idtr.cbIdt < 0x0fff)
+# if defined(RT_OS_LINUX) || defined(RT_OS_SOLARIS)
+        if (Idtr.cbIdt <  0x0fff)
+# else
+        if (Idtr.cbIdt != 0xffff)
+# endif
         {
             pVCpu->hm.s.vmx.fRestoreHostFlags |= VMX_RESTORE_HOST_IDTR;
@@ -6638,6 +6653,6 @@
         Log4Func(("Restoring Host State: fRestoreHostFlags=%#RX32 HostCpuId=%u\n", pVCpu->hm.s.vmx.fRestoreHostFlags, idCpu));
         VMXRestoreHostState(pVCpu->hm.s.vmx.fRestoreHostFlags, &pVCpu->hm.s.vmx.RestoreHost);
-        pVCpu->hm.s.vmx.fRestoreHostFlags = 0;
-    }
+    }
+    pVCpu->hm.s.vmx.fRestoreHostFlags = 0;
 #endif
 
@@ -6869,8 +6884,7 @@
         if (   (pVCpu->hm.s.vmx.fRestoreHostFlags & VMX_RESTORE_HOST_REQUIRED)
             && (pVCpu->hm.s.vmx.fRestoreHostFlags & ~VMX_RESTORE_HOST_REQUIRED))
-        {
             VMXRestoreHostState(pVCpu->hm.s.vmx.fRestoreHostFlags, &pVCpu->hm.s.vmx.RestoreHost);
-            pVCpu->hm.s.vmx.fRestoreHostFlags = 0;
-        }
+        pVCpu->hm.s.vmx.fRestoreHostFlags = 0;
+
         /* Restore the host MSRs as we're leaving VT-x context. */
         if (   pVM->hm.s.fAllow64BitGuests
