(besides a more reliable confirmation - or otherwise - that this indeed
is an issue with 32-bit guests only).

While I think I have ruled out the TLB flush time stamp setting still
happening too early / wrongly in certain cases, there's a small
debugging patch that I would hope could help prove this one or the
other way (see below).

Btw: You've said earlier that there wouldn't be a domain number in
the panic message. However,

(XEN) RFLAGS: 0000000000010246   CONTEXT: hypervisor (d14v3)

has it (at the end: domain 14, vCPU 3). Just in case this helps
identifying further useful pieces of information.

Jan

--- xen/arch/x86/mm.c.orig
+++ xen/arch/x86/mm.c
@@ -578,7 +578,11 @@ static inline void set_tlbflush_timestam
      */
     if ( !(page->count_info & PGC_page_table) ||
          !shadow_mode_enabled(page_get_owner(page)) )
+    {
+        /* NB: This depends on WRAP_MASK in flushtlb.c to be <= 0xffff. */
+        ASSERT(!page->linear_pt_count);
         page_set_tlbflush_timestamp(page);
+    }
 }
 
 const char __section(".bss.page_aligned.const") __aligned(PAGE_SIZE)