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] [PATCH 10/14] xen: events: maintain a list of Xen interr

To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 10/14] xen: events: maintain a list of Xen interrupts
From: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Date: Thu, 10 Mar 2011 08:43:15 +0000
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Thu, 10 Mar 2011 00:44:36 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20110310052218.GB10574@xxxxxxxxxxxx>
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: <1299692459.17339.700.camel@xxxxxxxxxxxxxxxxxxxxxx> <1299692486-28634-10-git-send-email-ian.campbell@xxxxxxxxxx> <20110310052218.GB10574@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Thu, 2011-03-10 at 05:22 +0000, Konrad Rzeszutek Wilk wrote:
> On Wed, Mar 09, 2011 at 05:41:22PM +0000, Ian Campbell wrote:
> > In a PVHVM kernel not all interrupts are Xen interrupts (APIC interrupts 
> > can also be present).
> > 
> > Currently we get away with walking over all interrupts because the
> > lookup in the irq_info array simply returns IRQT_UNBOUND and we ignore
> > it. However this array will be going away in a future patch so we need
> > to manually track which interrupts have been allocated by the Xen
> > events infrastructure.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
> > ---
> >  drivers/xen/events.c |   59 
> > +++++++++++++++++++++++++++++++++++++------------
> >  1 files changed, 44 insertions(+), 15 deletions(-)
> > 
> > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > index cf372d4..e119989 100644
> > --- a/drivers/xen/events.c
> > +++ b/drivers/xen/events.c
> > @@ -56,6 +56,8 @@
> >   */
> >  static DEFINE_SPINLOCK(irq_mapping_update_lock);
> >  
> > +static LIST_HEAD(xen_irq_list_head);
> > +
> >  /* IRQ <-> VIRQ mapping. */
> >  static DEFINE_PER_CPU(int [NR_VIRQS], virq_to_irq) = {[0 ... NR_VIRQS-1] = 
> > -1};
> >  
> > @@ -85,7 +87,9 @@ enum xen_irq_type {
> >   */
> >  struct irq_info
> >  {
> > +   struct list_head list;
> >     enum xen_irq_type type; /* type */
> > +   unsigned irq;
> >     unsigned short evtchn;  /* event channel */
> >     unsigned short cpu;     /* cpu bound */
> >  
> > @@ -135,6 +139,7 @@ static void xen_irq_info_common_init(struct irq_info 
> > *info,
> >     BUG_ON(info->type != IRQT_UNBOUND && info->type != type);
> >  
> >     info->type = type;
> > +   info->irq = irq;
> >     info->evtchn = evtchn;
> >     info->cpu = cpu;
> >  
> > @@ -311,10 +316,11 @@ static void init_evtchn_cpu_bindings(void)
> >  {
> >     int i;
> >  #ifdef CONFIG_SMP
> > -   struct irq_desc *desc;
> > +   struct irq_info *info;
> >  
> >     /* By default all event channels notify CPU#0. */
> > -   for_each_irq_desc(i, desc) {
> > +   list_for_each_entry(info, &xen_irq_list_head, list) {
> > +           struct irq_desc *desc = irq_to_desc(info->irq);
> >             cpumask_copy(desc->irq_data.affinity, cpumask_of(0));
> >     }
> >  #endif
> > @@ -397,6 +403,21 @@ static void unmask_evtchn(int port)
> >     put_cpu();
> >  }
> >  
> > +static void xen_irq_init(unsigned irq)
> > +{
> > +   struct irq_info *info;
> > +   struct irq_desc *desc = irq_to_desc(irq);
> > +
> > +   /* By default all event channels notify CPU#0. */
> > +   cpumask_copy(desc->irq_data.affinity, cpumask_of(0));
> > +
> > +   info = &irq_info[irq];
> > +
> > +   info->type = IRQT_UNBOUND;
> > +
> > +   list_add_tail(&info->list, &xen_irq_list_head);
> 
> Should we use some form of spinlock lock? Just in case
> there are two drivers that are being unloaded?

The callers are xen_allocate_irq_dynamic and xen_allocate_irq_gsi both
of which expect to be protected by irq_mapping_update_lock already.


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

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