Re: [Xen-devel] [xen-unstable test] 11574: tolerable FAIL

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Ian Jackson writes ("Re: [xen-unstable test] 11574: tolerable FAIL"):
> This is a host-specific, but deterministic, failure.  My bisector has
> been working on it (the basis pass was in November so there has been a
> lot of ground to cover and I had to make some new arrangements to be
> able to run an ad-hoc bisection of this problem) and the results so
> far are fingering changesets between 24367:537ceb11d51e (bad) and
> 24362:d35bedf334f2 (good).

The bisector is now minded to blame this changeset:

  changeset:   24367:537ceb11d51e
  user:        Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx>
  date:        Tue Dec 06 20:31:49 2011 +0000
  files:       xen/arch/x86/hvm/hvm.c
  description:
  Improve handling of nested page faults

  Add checks for access type. Be less reliant on implicit semantics.

  Signed-off-by: Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx>
  Acked-by: Tim Deegan <tim@xxxxxxx>
  Committed-by: Tim Deegan <tim@xxxxxxx>

It's doing a couple more before-and-after repros to be sure, but this
looks like a plausible candidate.  Full diff below.

I'm not an expert on this area.  Perhaps someone could speculate what
Windows is doing that is triggering one of these new checks ?

Ian.

# HG changeset patch
# User Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx>
# Date 1323203509 0
# Node ID 537ceb11d51ef60cd4abffd2f54de0ae0ca50008
# Parent  534b2a15e6695dfd8866c0ff626b002cbf57991a
Improve handling of nested page faults

Add checks for access type. Be less reliant on implicit semantics.

Signed-off-by: Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx>
Acked-by: Tim Deegan <tim@xxxxxxx>
Committed-by: Tim Deegan <tim@xxxxxxx>

diff -r 534b2a15e669 -r 537ceb11d51e xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c    Tue Dec 06 20:10:32 2011 +0000
+++ b/xen/arch/x86/hvm/hvm.c    Tue Dec 06 20:31:49 2011 +0000
@@ -1288,7 +1288,8 @@ int hvm_hap_nested_page_fault(unsigned l
      * If this GFN is emulated MMIO or marked as read-only, pass the fault
      * to the mmio handler.
      */
-    if ( (p2mt == p2m_mmio_dm) || (p2mt == p2m_ram_ro) )
+    if ( (p2mt == p2m_mmio_dm) || 
+         (access_w && (p2mt == p2m_ram_ro)) )
     {
         if ( !handle_mmio() )
             hvm_inject_exception(TRAP_gp_fault, 0, 0);
@@ -1302,7 +1303,7 @@ int hvm_hap_nested_page_fault(unsigned l
         p2m_mem_paging_populate(v->domain, gfn);
 
     /* Mem sharing: unshare the page and try again */
-    if ( p2mt == p2m_ram_shared )
+    if ( access_w && (p2mt == p2m_ram_shared) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
         mem_sharing_unshare_page(p2m->domain, gfn, 0);
@@ -1319,14 +1320,17 @@ int hvm_hap_nested_page_fault(unsigned l
          * a large page, we do not change other pages type within that large
          * page.
          */
-        paging_mark_dirty(v->domain, mfn_x(mfn));
-        p2m_change_type(v->domain, gfn, p2m_ram_logdirty, p2m_ram_rw);
+        if ( access_w )
+        {
+            paging_mark_dirty(v->domain, mfn_x(mfn));
+            p2m_change_type(v->domain, gfn, p2m_ram_logdirty, p2m_ram_rw);
+        }
         rc = 1;
         goto out_put_gfn;
     }
 
     /* Shouldn't happen: Maybe the guest was writing to a r/o grant mapping? */
-    if ( p2mt == p2m_grant_map_ro )
+    if ( access_w && (p2mt == p2m_grant_map_ro) )
     {
         gdprintk(XENLOG_WARNING,
                  "trying to write to read-only grant mapping\n");

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