xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Andrii Anisov <andrii.anisov@gmail.com>
To: Julien Grall <julien.grall@arm.com>, xen-devel@lists.xenproject.org
Cc: andre.przywara@arm.com, sstabellini@kernel.org
Subject: Re: [PATCH for-next] xen/arm: irq: Don't use _IRQ_PENDING when handling host interrupt
Date: Fri, 5 Apr 2019 17:16:31 +0300	[thread overview]
Message-ID: <f916ec14-a1bd-c4bd-0287-655cfb831d89@gmail.com> (raw)
In-Reply-To: <20190128155909.14289-1-julien.grall@arm.com>



On 28.01.19 17:59, Julien Grall wrote:
> While SPIs are shared between CPU, it is not possible to receive the
> same interrupts on a different CPU while the interrupt is in active
> state. The deactivation of the interrupt is done at the end of the
> handling.
> 
> This means the _IRQ_PENDING logic is unecessary on Arm as a same
> interrupt can never come up while in the loop. So remove it to
> simplify the interrupt handle code.

What about _IRQ_PENDING macro itself?
Any reasons to not eliminate it?

> 
> Signed-off-by: Julien Grall <julien.grall@arm.com>
> ---
>   xen/arch/arm/irq.c | 32 ++++++++++----------------------
>   1 file changed, 10 insertions(+), 22 deletions(-)
> 
> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
> index c51cf333ce..3877657a52 100644
> --- a/xen/arch/arm/irq.c
> +++ b/xen/arch/arm/irq.c
> @@ -199,6 +199,7 @@ int request_irq(unsigned int irq, unsigned int irqflags,
>   void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq)
>   {
>       struct irq_desc *desc = irq_to_desc(irq);
> +    struct irqaction *action;
>   
>       perfc_incr(irqs);
>   
> @@ -242,35 +243,22 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq)
>           goto out_no_end;
>       }
>   
> -    set_bit(_IRQ_PENDING, &desc->status);
> -
> -    /*
> -     * Since we set PENDING, if another processor is handling a different
> -     * instance of this same irq, the other processor will take care of it.
> -     */
> -    if ( test_bit(_IRQ_DISABLED, &desc->status) ||
> -         test_bit(_IRQ_INPROGRESS, &desc->status) )
> +    if ( test_bit(_IRQ_DISABLED, &desc->status) )
>           goto out;
>   
>       set_bit(_IRQ_INPROGRESS, &desc->status);
>   
> -    while ( test_bit(_IRQ_PENDING, &desc->status) )
> -    {
> -        struct irqaction *action;
> +    action = desc->action;
>   
> -        clear_bit(_IRQ_PENDING, &desc->status);
> -        action = desc->action;
> +    spin_unlock_irq(&desc->lock);
>   
> -        spin_unlock_irq(&desc->lock);
> -
> -        do
> -        {
> -            action->handler(irq, action->dev_id, regs);
> -            action = action->next;
> -        } while ( action );
> +    do
> +    {
> +        action->handler(irq, action->dev_id, regs);
> +        action = action->next;
> +    } while ( action );
>   
> -        spin_lock_irq(&desc->lock);
> -    }
> +    spin_lock_irq(&desc->lock);
>   
>       clear_bit(_IRQ_INPROGRESS, &desc->status);
>   
> 

-- 
Sincerely,
Andrii Anisov.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

WARNING: multiple messages have this Message-ID (diff)
From: Andrii Anisov <andrii.anisov@gmail.com>
To: Julien Grall <julien.grall@arm.com>, xen-devel@lists.xenproject.org
Cc: andre.przywara@arm.com, sstabellini@kernel.org
Subject: Re: [Xen-devel] [PATCH for-next] xen/arm: irq: Don't use _IRQ_PENDING when handling host interrupt
Date: Fri, 5 Apr 2019 17:16:31 +0300	[thread overview]
Message-ID: <f916ec14-a1bd-c4bd-0287-655cfb831d89@gmail.com> (raw)
Message-ID: <20190405141631.raNyCpdJMxB8yOuwfeOnCdwr6pKMVzdZzionwcB9l74@z> (raw)
In-Reply-To: <20190128155909.14289-1-julien.grall@arm.com>



On 28.01.19 17:59, Julien Grall wrote:
> While SPIs are shared between CPU, it is not possible to receive the
> same interrupts on a different CPU while the interrupt is in active
> state. The deactivation of the interrupt is done at the end of the
> handling.
> 
> This means the _IRQ_PENDING logic is unecessary on Arm as a same
> interrupt can never come up while in the loop. So remove it to
> simplify the interrupt handle code.

What about _IRQ_PENDING macro itself?
Any reasons to not eliminate it?

> 
> Signed-off-by: Julien Grall <julien.grall@arm.com>
> ---
>   xen/arch/arm/irq.c | 32 ++++++++++----------------------
>   1 file changed, 10 insertions(+), 22 deletions(-)
> 
> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
> index c51cf333ce..3877657a52 100644
> --- a/xen/arch/arm/irq.c
> +++ b/xen/arch/arm/irq.c
> @@ -199,6 +199,7 @@ int request_irq(unsigned int irq, unsigned int irqflags,
>   void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq)
>   {
>       struct irq_desc *desc = irq_to_desc(irq);
> +    struct irqaction *action;
>   
>       perfc_incr(irqs);
>   
> @@ -242,35 +243,22 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq)
>           goto out_no_end;
>       }
>   
> -    set_bit(_IRQ_PENDING, &desc->status);
> -
> -    /*
> -     * Since we set PENDING, if another processor is handling a different
> -     * instance of this same irq, the other processor will take care of it.
> -     */
> -    if ( test_bit(_IRQ_DISABLED, &desc->status) ||
> -         test_bit(_IRQ_INPROGRESS, &desc->status) )
> +    if ( test_bit(_IRQ_DISABLED, &desc->status) )
>           goto out;
>   
>       set_bit(_IRQ_INPROGRESS, &desc->status);
>   
> -    while ( test_bit(_IRQ_PENDING, &desc->status) )
> -    {
> -        struct irqaction *action;
> +    action = desc->action;
>   
> -        clear_bit(_IRQ_PENDING, &desc->status);
> -        action = desc->action;
> +    spin_unlock_irq(&desc->lock);
>   
> -        spin_unlock_irq(&desc->lock);
> -
> -        do
> -        {
> -            action->handler(irq, action->dev_id, regs);
> -            action = action->next;
> -        } while ( action );
> +    do
> +    {
> +        action->handler(irq, action->dev_id, regs);
> +        action = action->next;
> +    } while ( action );
>   
> -        spin_lock_irq(&desc->lock);
> -    }
> +    spin_lock_irq(&desc->lock);
>   
>       clear_bit(_IRQ_INPROGRESS, &desc->status);
>   
> 

-- 
Sincerely,
Andrii Anisov.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  parent reply	other threads:[~2019-04-05 14:16 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-28 15:59 [PATCH for-next] xen/arm: irq: Don't use _IRQ_PENDING when handling host interrupt Julien Grall
2019-03-19 23:28 ` Julien Grall
2019-04-05 14:16 ` Andrii Anisov [this message]
2019-04-05 14:16   ` [Xen-devel] " Andrii Anisov
2019-04-05 14:34   ` Julien Grall
2019-04-05 14:34     ` [Xen-devel] " Julien Grall
2019-04-05 14:59     ` Andrii Anisov
2019-04-05 14:59       ` [Xen-devel] " Andrii Anisov
2019-04-16 21:51 ` Stefano Stabellini
2019-04-16 21:51   ` [Xen-devel] " Stefano Stabellini
2019-04-16 22:07   ` Julien Grall
2019-04-16 22:07     ` [Xen-devel] " Julien Grall
2019-04-17 17:12     ` Stefano Stabellini
2019-04-17 17:12       ` [Xen-devel] " Stefano Stabellini
2019-04-17 17:24       ` Julien Grall
2019-04-17 17:24         ` [Xen-devel] " Julien Grall
2019-04-17 17:27         ` Stefano Stabellini
2019-04-17 17:27           ` [Xen-devel] " Stefano Stabellini
2019-05-20 15:15           ` Julien Grall
2019-05-20 15:15             ` [Xen-devel] " Julien Grall
2019-05-20 21:04             ` Stefano Stabellini
2019-05-20 21:04               ` [Xen-devel] " Stefano Stabellini
2019-05-21 10:11               ` Julien Grall
2019-05-21 10:11                 ` [Xen-devel] " Julien Grall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f916ec14-a1bd-c4bd-0287-655cfb831d89@gmail.com \
    --to=andrii.anisov@gmail.com \
    --cc=andre.przywara@arm.com \
    --cc=julien.grall@arm.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).