From mboxrd@z Thu Jan  1 00:00:00 1970
From: Chuck Anderson <chuck.anderson@oracle.com>
Subject: Re: 2.6.32 PV Xen donU guest panic on nested call to
	arch_enter_lazy_mmu_mode()
Date: Wed, 08 Dec 2010 22:50:44 -0800
Message-ID: <4D007C44.5010307@oracle.com>
References: <4CFED74D.1040304@oracle.com> <4D0006A3.8010307@goop.org>
	<4D002F29.3080709@oracle.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <4D002F29.3080709@oracle.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Jan Beulich <JBeulich@novell.com>
List-Id: xen-devel@lists.xenproject.org

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