[PATCH 1/3] x86/mm: fix #GP(0) in switch_cr3_cr4()

["Jan Beulich" <JBeulich@suse.com>]

With "pcid=no-xpti" and opposite XPTI settings in two 64-bit PV domains
(achievable with one of "xpti=no-dom0" or "xpti=no-domu"), switching
from a PCID-disabled to a PCID-enabled 64-bit PV domain fails to set
CR4.PCIDE in time, as CR4.PGE would not be set in either (see
pv_guest_cr4_to_real_cr4(), in particular as used by write_ptbase()),
and hence the early CR4 write would be skipped.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -122,6 +122,7 @@ void switch_cr3_cr4(unsigned long cr3, u
         write_cr4(old_cr4);
     }
     else if ( use_invpcid )
+    {
         /*
          * Flushing the TLB via INVPCID is necessary only in case PCIDs are
          * in use, which is true only with INVPCID being available.
@@ -132,6 +133,19 @@ void switch_cr3_cr4(unsigned long cr3, u
          */
         invpcid_flush_all_nonglobals();
 
+        /*
+         * CR4.PCIDE needs to be set before the CR3 write below. Otherwise
+         * - the CR3 write will fault when CR3.NOFLUSH is set (which is the
+         *   case normally),
+         * - the subsequent CR4 write will fault if CR3.PCID != 0.
+         */
+        if ( (old_cr4 & X86_CR4_PCIDE) < (cr4 & X86_CR4_PCIDE) )
+        {
+            write_cr4(cr4);
+            old_cr4 = cr4;
+        }
+    }
+
     /*
      * If we don't change PCIDs, the CR3 write below needs to flush this very
      * PCID, even when a full flush was performed above, as we are currently





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