WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] 2.6.32 PV Xen donU guest panic on nested call to arch_en

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] 2.6.32 PV Xen donU guest panic on nested call to arch_enter_lazy_mmu_mode()
From: Chuck Anderson <chuck.anderson@xxxxxxxxxx>
Date: Wed, 08 Dec 2010 22:50:44 -0800
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
Delivery-date: Wed, 08 Dec 2010 22:53:00 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4D002F29.3080709@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4CFED74D.1040304@xxxxxxxxxx> <4D0006A3.8010307@xxxxxxxx> <4D002F29.3080709@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.22 (X11/20090608)
Jeremy,
Looking at copy_pte_range(), the stale update scenario I described below can't happen. I believe the deadlock could happen but that is not a lazy/not lazy MMU update issue.

Here is an extract from your proposed patch:

static inline void enter_lazy(enum paravirt_lazy_mode mode)
{
+    if (in_interrupt())
+        return;
+
    BUG_ON(percpu_read(paravirt_lazy_mode) != PARAVIRT_LAZY_NONE);

My vote is for something like:

static inline void enter_lazy(enum paravirt_lazy_mode mode)
{
-       BUG_ON(percpu_read(paravirt_lazy_mode) != PARAVIRT_LAZY_NONE);
+       /*
+        * Switch modes only if we are not in an interrupt context.
+        * The mode is ignored while handling an interrupt.
+        */
+       if (!in_interrupt()) {
+ BUG_ON(percpu_read(paravirt_lazy_mode) != PARAVIRT_LAZY_NONE);

-       percpu_write(paravirt_lazy_mode, mode);
+               percpu_write(paravirt_lazy_mode, mode);
+       }
}

static void leave_lazy(enum paravirt_lazy_mode mode)
{
-        BUG_ON(percpu_read(paravirt_lazy_mode) != mode);
+      /*
+       * Switch modes only if we are not in an interrupt context.
+       * The mode is ignored while handling an interrupt.
+       */
+      if (!in_interrupt()) {
+              BUG_ON(percpu_read(paravirt_lazy_mode) != mode);

-        percpu_write(paravirt_lazy_mode, PARAVIRT_LAZY_NONE);
+              percpu_write(paravirt_lazy_mode, PARAVIRT_LAZY_NONE);
+       }
}

Thanks,
Chuck

Chuck Anderson wrote:
Jeremy,
Is it possible for an ongoing lazy mode update to have batched some MMU updates; an interrupt occurs; an interrupt routine does a non-lazy MMU update for a PTE that is also in the lazy update queue; that update is overwritten on return from the interrupt when the update queue is flushed? Or are the PTE updates protected by a lock? If they are, wouldn't we deadlock in the interrupt routine when it tries to obtain that (I assume) spinlock?
Chuck

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