This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-changelog] [xen-3.4-testing] x86 shadow: Update cr3 in PAE mode whe

To: xen-changelog@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-changelog] [xen-3.4-testing] x86 shadow: Update cr3 in PAE mode when guest walk succeed but shadow walk fails
From: "Xen patchbot-3.4-testing" <patchbot-3.4-testing@xxxxxxxxxxxxxxxxxxx>
Date: Mon, 19 Oct 2009 04:10:13 -0700
Delivery-date: Mon, 19 Oct 2009 04:10:26 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-changelog-request@lists.xensource.com?subject=help>
List-id: BK change log <xen-changelog.lists.xensource.com>
List-post: <mailto:xen-changelog@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-changelog>, <mailto:xen-changelog-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-changelog>, <mailto:xen-changelog-request@lists.xensource.com?subject=unsubscribe>
Reply-to: xen-devel@xxxxxxxxxxxxxxxxxxx
Sender: xen-changelog-bounces@xxxxxxxxxxxxxxxxxxx
# HG changeset patch
# User Keir Fraser <keir.fraser@xxxxxxxxxx>
# Date 1255950233 -3600
# Node ID 6a4ff02131a67a73b223efff6e7d1bf475156cce
# Parent  8c7e71d2fdb2db88fb21a4a012c08dac8ef08c2b
x86 shadow: Update cr3 in PAE mode when guest walk succeed but shadow walk fails

When running in PAE mode, Windows 7 (apparently) will occasionally
switch cr3 with one of the L3 entries invalid, make it valid, and then
expect the hardware to load the new value.  (This behavior is
explicitly not promised in the hardware manuals.)  This leads to a
situation where on a shadow fault, the guest walk succeeds but the
shadow walk fails.  The code assumes this can only happen when the
domain is dying, and makes an ASSERT() to that effect.  So currently,
in debug mode, this will cause the host to crash; in non-debug mode,
this will cause a page-fault loop.

This patch solves the problem by calling update_cr3() in that path
when the guest is in PAE mode, and only ASSERT()ing when the guest is
not in PAE mode.  The guest will get one spurious page fault, but
subsequent accesses will succeed.

Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
xen-unstable changeset:   20337:ba5fe6e2abb6
xen-unstable date:        Mon Oct 19 10:56:58 2009 +0100
 xen/arch/x86/mm/shadow/multi.c |    9 +++++++++
 1 files changed, 9 insertions(+)

diff -r 8c7e71d2fdb2 -r 6a4ff02131a6 xen/arch/x86/mm/shadow/multi.c
--- a/xen/arch/x86/mm/shadow/multi.c    Fri Oct 16 08:59:33 2009 +0100
+++ b/xen/arch/x86/mm/shadow/multi.c    Mon Oct 19 12:03:53 2009 +0100
@@ -3180,7 +3180,16 @@ static int sh_page_fault(struct vcpu *v,
          * are OK, this can only have been caused by a failed
          * shadow_set_l*e(), which will have crashed the guest.
          * Get out of the fault handler immediately. */
+        /* Windows 7 apparently relies on the hardware to do something
+         * it explicitly hasn't promised to do: load l3 values after
+         * the cr3 is loaded.
+         * In any case, in the PAE case, the ASSERT is not true; it can
+         * happen because of actions the guest is taking. */
+        v->arch.paging.mode->update_cr3(v, 0);
         trace_shadow_gen(TRC_SHADOW_DOMF_DYING, va);
         return 0;

Xen-changelog mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-changelog] [xen-3.4-testing] x86 shadow: Update cr3 in PAE mode when guest walk succeed but shadow walk fails, Xen patchbot-3.4-testing <=