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: Ian Campbell <ian.campbell@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 10/14] xen: events: maintain a list of Xen interrupts
From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date: Thu, 10 Mar 2011 00:22:18 -0500
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Wed, 09 Mar 2011 21:24:09 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1299692486-28634-10-git-send-email-ian.campbell@xxxxxxxxxx>
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>
References: <1299692459.17339.700.camel@xxxxxxxxxxxxxxxxxxxxxx> <1299692486-28634-10-git-send-email-ian.campbell@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.20 (2009-06-14)
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?

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

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