From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chuck Anderson Subject: Re: 2.6.32 PV Xen donU guest panic on nested call to arch_enter_lazy_mmu_mode() Date: Wed, 08 Dec 2010 17:21:45 -0800 Message-ID: <4D002F29.3080709@oracle.com> References: <4CFED74D.1040304@oracle.com> <4D0006A3.8010307@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4D0006A3.8010307@goop.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jeremy Fitzhardinge Cc: "xen-devel@lists.xensource.com" , Jan Beulich List-Id: xen-devel@lists.xenproject.org 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 Jeremy Fitzhardinge wrote: > Disabling interrupts would cause too much latency. I think we may have > done this at one point, but it is very antisocial. > > Since lazy mode is effectively disabled in interrupt handlers anyway, it > should just be enough to ignore enter/leave requests. Does this work > for you? > > From: Jeremy Fitzhardinge > Date: Wed, 8 Dec 2010 14:21:16 -0800 > Subject: [PATCH] x86/paravirt: don't enter/leave lazy mode in interrupts. > > We already ignore the current state of lazy mode in interrupts, but we > should also ignore any attempt to enter/leave lazy mode within > an interrupt context. > > enter_lazy() will BUG if it sees an attempt at a nested entry to lazy > mode, which is generally an error. However, it's possible that an > interrupt handler may do something that would trigger a batched MMU > update, for example, and that could interrupt an existing batched update.