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] Re: [PATCH] xen: events: do not unmask polled ipis on re

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH] xen: events: do not unmask polled ipis on restore.
From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Date: Mon, 1 Nov 2010 14:51:23 +0000
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 01 Nov 2010 07:52:15 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1288374733.8069.57.camel@xxxxxxxxxxxxxxxxxxxxx>
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>
Organization: Citrix Systems, Inc.
References: <1288341238-3059-1-git-send-email-ian.campbell@xxxxxxxxxx> <4CCAF9E1.70902@xxxxxxxx> <1288374733.8069.57.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Fri, 2010-10-29 at 18:52 +0100, Ian Campbell wrote:
> 
> 
> > I wonder if this shouldn't be done at the irq layer, based on the 
> > desc's irq state?
> 
> It looks like suspend_device_irqs/resume_device_irqs takes care of the
> mask/unmask element of restore for us (including unmasking irqs marked
> with IRQF_NO_SUSPEND when appropriate). So we know the evtchn will be
> masked on save and Xen brings us back up with all evtchns masked so
> all restore_cpu_ipis needs to do is the rebinding of ipi to evtchn? 

A naive attempt at this (i.e. remove the unmask_evtchn calls from
restore_cpu_{ipis,virqs}) doesn't work, since we (unsurprisingly) end up
with some evtchn's remaining masked...

I'll take another look. It's possible that this will also interact with
Stefano's changes to the irq_chip interactions since he is trying to
ensure that our callbacks have the semantics expected by the core.

BTW, do you think the polled-only IPI are unusual/special enough to have
their own interface with the event channel core (e.g.
bind_polled_ipi_to_irq) even if the internals of the implementation
doesn't turn into anything particularly unusual?

Ian.


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

<Prev in Thread] Current Thread [Next in Thread>