[Xen-changelog] [xen-unstable] [XEN] Don't pass spurious fast-path faults to the guest at all.

[Xen patchbot-unstable <patchbot-unstable@xxxxxxxxxxxxxxxxxxx>]

# HG changeset patch
# User Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>
# Date 1166616278 0
# Node ID 988d3a63d9befa9fd68b986f293b935f2ffc02e5
# Parent  c75d6f2aad7a64b66b814ade1af9669ea456a69a
[XEN] Don't pass spurious fast-path faults to the guest at all.
Instead, retry and get a sensible fault from the hardware next time.
Signed-off-by: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>
---
 xen/arch/x86/mm/shadow/multi.c |   11 ++++-------
 1 files changed, 4 insertions(+), 7 deletions(-)

diff -r c75d6f2aad7a -r 988d3a63d9be xen/arch/x86/mm/shadow/multi.c
--- a/xen/arch/x86/mm/shadow/multi.c    Wed Dec 20 12:03:07 2006 +0000
+++ b/xen/arch/x86/mm/shadow/multi.c    Wed Dec 20 12:04:38 2006 +0000
@@ -2645,14 +2645,11 @@ static int sh_page_fault(struct vcpu *v,
         else
         {
             /* This should be exceptionally rare: another vcpu has fixed
-             * the tables between the fault and our reading the l1e.
-             * Fall through to the normal fault handing logic */
+             * the tables between the fault and our reading the l1e. 
+             * Retry and let the hardware give us the right fault next time. */
             perfc_incrc(shadow_fault_fast_fail);
-            SHADOW_PRINTK("fast path false alarm!\n");
-            /* Don't pass the reserved-bit bit: if we look at the fault 
-             * below and decide to pass it to the guest, the reserved-bit
-             * bit won't make sense there. */
-            regs->error_code &= ~PFEC_reserved_bit;
+            SHADOW_PRINTK("fast path false alarm!\n");            
+            return EXCRET_fault_fixed;
         }
     }
 #endif /* SHOPT_FAST_FAULT_PATH */

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