Changeset 50426 in vbox

Timestamp:

Feb 12, 2014 1:16:33 PM (11 years ago)

Author:

vboxsync

svn:sync-xref-src-repo-rev:

92215

Message:

HMR0VMX.cpp: Hacked hmR0VmxSaveHostSegmentRegs to call VMXRestoreHostState when necessary so we don't corrupt the host state should HM_CHANGED_HOST_CONTEXT be set and executed without leaving the HM ring-0 context. Also restricted the dont-bother-to-restore-host-Idtr.limit condition to only include Linux and Solaris as this is known to cause trouble on Windows and Darwin already (HMR0Mixed.mac needs tweaking and testing to complete this change.)

File:

• trunk/src/VBox/VMM/VMMR0/HMVMXR0.cpp (modified) (5 diffs)

trunk/src/VBox/VMM/VMMR0/HMVMXR0.cpp

@@ -2750 +2750 @@
         { \
             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 +2774 @@
     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 +2907 @@
 
         /*
-         * 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 +6653 @@
         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 +6884 @@
         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