[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] map_domain_page_global() and interrupts


  • To: Andrew Gallagher <ajcg@xxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Mon, 30 Jul 2007 19:12:13 +0100
  • Delivery-date: Mon, 30 Jul 2007 11:06:22 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcfS1SclZcdgBT7IEdyr+AAWy6hiGQ==
  • Thread-topic: [Xen-devel] map_domain_page_global() and interrupts

!in_irq() because the function is not reentrant.

local_irq_is_enabled() because the function uses flush_tlb_all() which must
be able to IPI remote CPUs.  We mustn't have them stuck spinning on
globalmap_lock with interrupts disabled -- that would result in deadlock.

 -- Keir

On 29/7/07 01:02, "Andrew Gallagher" <ajcg@xxxxxxxxxxx> wrote:

> In the file xen/arch/x86/x86_32/domain_page.c, the
> map_domain_page_global function has the following assertion:
> ASSERT(!in_irq() && local_irq_is_enabled()).  This assertion is followed
> by use of a spin lock without disabling then reenabling irqs.
> 
> The assertion that the function is not called from an interrupted context
> seems to flag this function as not interrupt safe.  Why is this?  Is the
> use of the IOREMAP_VIRT not interrupt safe itself.  The only reason this
> seems to be not interrupt safe is becuase of the use of a spinlock without
> disabling and reenabling irqs.
> 
> My question is that, if interrupts are disabled then reenabled before and
> after acquiring and releasing the spinlock, is it then ok to call this
> function from the context of an interrupt?
> 
> Thanks,
> Andrew
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.