[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [PATCH] Update cr3 in PAE mode when guest walk succeed but shadow walk fails


  • To: xen-devel@xxxxxxxxxxxxxxxxxxx
  • From: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
  • Date: Fri, 16 Oct 2009 14:09:20 +0100
  • Delivery-date: Fri, 16 Oct 2009 06:10:28 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=Y3qEmqy4fOcm/FpMDZHRGqzXXNURRuwvop3bw2pjWhUvo+CjQjqI6TjxevyDekQQmI RXm/j+8RtFvPcQdM3bc5Mo3tTJt6mlDFPuq6mHv4d6h7NeKAVJdHPx0von3/2poMs0FH AsdicgFMViSyqrTF8H/X+CGTvD0I0q1iWyue8=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

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.

The attached 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>

Attachment: 20091016-update-cr3-on-shadow-failure.diff
Description: Text Data

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.