1.1 --- a/xen/arch/x86/flushtlb.c	Mon Nov 01 08:11:55 2004 +0000
     1.2 +++ b/xen/arch/x86/flushtlb.c	Mon Nov 01 10:00:03 2004 +0000
     1.3 @@ -41,7 +41,7 @@ void write_cr3(unsigned long cr3)
     1.4      t = tlbflush_clock;
     1.5      do {
     1.6          t1 = t2 = t;
     1.7 -        /* Clock wrapped: someone else is leading a global TLB shootodiown. */
     1.8 +        /* Clock wrapped: someone else is leading a global TLB shootdown. */
     1.9          if ( unlikely(t1 == 0) )
    1.10              goto skip_clocktick;
    1.11          t2 = (t + 1) & WRAP_MASK;
    1.12 @@ -60,7 +60,15 @@ void write_cr3(unsigned long cr3)
    1.13      __asm__ __volatile__ ( "mov"__OS" %0, %%cr3" : : "r" (cr3) : "memory" );
    1.14  
    1.15      /*
    1.16 -     * STEP 3. Update this CPU's timestamp.
    1.17 +     * STEP 3. Update this CPU's timestamp. Note that this happens *after*
    1.18 +     *         flushing the TLB, as otherwise we can race a NEED_FLUSH() test
    1.19 +     *         on another CPU. (e.g., other CPU sees the updated CPU stamp and
    1.20 +     *         so does not force a synchronous TLB flush, but the flush in this
    1.21 +     *         function hasn't yet occurred and so the TLB might be stale).
    1.22 +     *         The ordering would only actually matter if this function were
    1.23 +     *         interruptible, and something that abuses the stale mapping could
    1.24 +     *         exist in an interrupt handler. In fact neither of these is the
    1.25 +     *         case, so really we are being ultra paranoid.
    1.26       */
    1.27  
    1.28      tlbflush_time[smp_processor_id()] = t2;

     2.1 --- a/xen/arch/x86/memory.c	Mon Nov 01 08:11:55 2004 +0000
     2.2 +++ b/xen/arch/x86/memory.c	Mon Nov 01 10:00:03 2004 +0000
     2.3 @@ -1593,7 +1593,7 @@ void ptwr_flush(const int which)
     2.4          MEM_LOG("ptwr: Could not read pte at %p\n", ptep);
     2.5          /*
     2.6           * Really a bug. We could read this PTE during the initial fault,
     2.7 -         * and pagetables can't have changed meantime. XXX Multi-proc guests?
     2.8 +         * and pagetables can't have changed meantime. XXX Multi-CPU guests?
     2.9           */
    2.10          BUG();
    2.11      }
    2.12 @@ -1620,13 +1620,14 @@ void ptwr_flush(const int which)
    2.13          MEM_LOG("ptwr: Could not update pte at %p\n", ptep);
    2.14          /*
    2.15           * Really a bug. We could write this PTE during the initial fault,
    2.16 -         * and pagetables can't have changed meantime. XXX Multi-proc guests?
    2.17 +         * and pagetables can't have changed meantime. XXX Multi-CPU guests?
    2.18           */
    2.19          BUG();
    2.20      }
    2.21  
    2.22      /* Ensure that there are no stale writable mappings in any TLB. */
    2.23 -    __flush_tlb_one(l1va);
    2.24 +    /* NB. INVLPG is a serialising instruction: flushes pending updates. */
    2.25 +    __flush_tlb_one(l1va); /* XXX Multi-CPU guests? */
    2.26      PTWR_PRINTK("[%c] disconnected_l1va at %p now %08lx\n",
    2.27                  PTWR_PRINT_WHICH, ptep, pte);
    2.28  
    2.29 @@ -1766,7 +1767,7 @@ int ptwr_do_page_fault(unsigned long add
    2.30      {
    2.31          nl2e = mk_l2_pgentry(l2_pgentry_val(*pl2e) & ~_PAGE_PRESENT);
    2.32          update_l2e(pl2e, *pl2e, nl2e);
    2.33 -        flush_tlb();
    2.34 +        flush_tlb(); /* XXX Multi-CPU guests? */
    2.35      }
    2.36      
    2.37      /* Temporarily map the L1 page, and make a copy of it. */