All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: "Alistair Francis" <alistair.francis@wdc.com>,
	"Bob Eshleman" <bobbyeshleman@gmail.com>,
	"Connor Davis" <connojdavis@gmail.com>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Anthony PERARD" <anthony.perard@vates.tech>,
	"Michal Orzel" <michal.orzel@amd.com>,
	"Julien Grall" <julien@xen.org>,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Romain Caritey" <Romain.Caritey@microchip.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v1 11/14] xen/riscv: add external interrupt handling for hypervisor mode
Date: Tue, 15 Apr 2025 16:42:57 +0200	[thread overview]
Message-ID: <a8a23afe-ae62-4b88-bf53-db2e1ada164d@suse.com> (raw)
In-Reply-To: <1685488b8c1b48149e94bd3625c7b46b78c72e8e.1744126720.git.oleksii.kurochko@gmail.com>

On 08.04.2025 17:57, Oleksii Kurochko wrote:
> Implement functions necessarry to have working external interrupts in
> hypervisor mode. The following changes are done:
>  - Add a common function intc_handle_external_irq() to call APLIC specific
>    function to handle an interrupt.
>  - Update do_trap() function to handle IRQ_S_EXT case; add the check to catch
>    case when cause of trap is an interrupt.
>  - Add handle_interrrupt() member to intc_hw_operations structure.
>  - Enable local interrupt delivery for IMSIC by implementation and calling of
>    imsic_ids_local_delivery() in imsic_init();

Ah, here is where that call really belongs (see my question on the earlier
patch). Please make sure you series builds okay at every patch boundary.

> --- a/xen/arch/riscv/aplic.c
> +++ b/xen/arch/riscv/aplic.c
> @@ -261,6 +261,21 @@ static void aplic_set_irq_affinity(struct irq_desc *desc, const cpumask_t *mask)
>      spin_unlock(&aplic.lock);
>  }
>  
> +static void aplic_handle_interrupt(unsigned long cause, struct cpu_user_regs *regs)
> +{
> +    /* disable to avoid more external interrupts */
> +    csr_clear(CSR_SIE, 1UL << IRQ_S_EXT);

Didn't I see you use BIT() elsewhere? Would be nice to be overall consistent
at least within related code.

> +    /* clear the pending bit */
> +    csr_clear(CSR_SIP, 1UL << IRQ_S_EXT);
> +
> +    /* dispatch the interrupt */
> +    do_IRQ(regs, csr_swap(CSR_STOPEI, 0) >> TOPI_IID_SHIFT);
> +
> +    /* enable external interrupts */
> +    csr_set(CSR_SIE, 1UL << IRQ_S_EXT);
> +}

Why does "cause" need passing into here? I realize the function is used ...

> @@ -278,6 +293,7 @@ static const struct intc_hw_operations aplic_ops = {
>      .host_irq_type       = &aplic_host_irq_type,
>      .set_irq_priority    = aplic_set_irq_priority,
>      .set_irq_type        = aplic_set_irq_type,
> +    .handle_interrupt    = aplic_handle_interrupt,
>  };

... as a hook, yet it's still unclear whether (why) any other such hook
would need the cause to be passed in.

> @@ -33,6 +44,20 @@ do {                            \
>      csr_clear(CSR_SIREG, v);    \
>  } while (0)
>  
> +void imsic_ids_local_delivery(bool enable)

__init as long as the sole caller is such?

> --- a/xen/arch/riscv/include/asm/intc.h
> +++ b/xen/arch/riscv/include/asm/intc.h
> @@ -34,6 +34,8 @@ struct intc_hw_operations {
>      /* Set IRQ priority */
>      void (*set_irq_priority)(struct irq_desc *desc, unsigned int priority);
>  
> +    /* handle external interrupt */
> +    void (*handle_interrupt)(unsigned long cause, struct cpu_user_regs *regs);
>  };
>  
>  void intc_preinit(void);
> @@ -45,4 +47,7 @@ void register_intc_ops(const struct intc_hw_operations *ops);
>  struct irq_desc;
>  void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority);
>  
> +struct cpu_user_regs;

This is too late - you've used it above already. It either can be dropped,
or needs to move up.

> --- a/xen/arch/riscv/intc.c
> +++ b/xen/arch/riscv/intc.c
> @@ -51,6 +51,13 @@ static void intc_set_irq_priority(struct irq_desc *desc, unsigned int priority)
>      intc_hw_ops->set_irq_priority(desc, priority);
>  }
>  
> +void intc_handle_external_irqs(unsigned long cause, struct cpu_user_regs *regs)
> +{
> +    ASSERT(intc_hw_ops && intc_hw_ops->handle_interrupt);

I don't view such checks (on every interrupt) as very useful. If you checked
once early on - okay. But here you gain nothing at all ...

> +    intc_hw_ops->handle_interrupt(cause, regs);

... towards the use here, when considering a release build.


> @@ -83,3 +87,42 @@ void __init init_IRQ(void)
>      if ( init_irq_data() < 0 )
>          panic("initialization of IRQ data failed\n");
>  }
> +
> +/* Dispatch an interrupt */
> +void do_IRQ(struct cpu_user_regs *regs, unsigned int irq)
> +{
> +    struct irq_desc *desc = irq_to_desc(irq);
> +    struct irqaction *action;
> +
> +    irq_enter();
> +
> +    spin_lock(&desc->lock);
> +    desc->handler->ack(desc);
> +
> +    if ( test_bit(_IRQ_DISABLED, &desc->status) )
> +        goto out;
> +
> +    set_bit(_IRQ_INPROGRESS, &desc->status);

Same comment as on the earlier patch - atomic bitop when in a suitably
locked region?

> +    action = desc->action;
> +
> +    spin_unlock_irq(&desc->lock);
> +
> +#ifndef CONFIG_IRQ_HAS_MULTIPLE_ACTION

Stolen from Arm? What's this about?

> +    action->handler(irq, action->dev_id);
> +#else
> +    do {
> +        action->handler(irq, action->dev_id);
> +        action = action->next;
> +    } while ( action );
> +#endif /* CONFIG_IRQ_HAS_MULTIPLE_ACTION */
> +
> +    spin_lock_irq(&desc->lock);
> +
> +    clear_bit(_IRQ_INPROGRESS, &desc->status);

See above.

> +out:

Nit (you know what).

> @@ -128,6 +129,23 @@ void do_trap(struct cpu_user_regs *cpu_regs)
>          }
>          fallthrough;
>      default:
> +        if ( cause & CAUSE_IRQ_FLAG )
> +        {
> +            /* Handle interrupt */
> +            unsigned long icause = cause & ~CAUSE_IRQ_FLAG;
> +
> +            switch ( icause )
> +            {
> +            case IRQ_S_EXT:
> +                intc_handle_external_irqs(cause, cpu_regs);
> +                break;
> +            default:

Nit: Blank line please between non-fall-through case blocks.

Jan


  reply	other threads:[~2025-04-15 14:43 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-08 15:57 [PATCH v1 00/14] riscv: introduce basic UART support and interrupts for hypervisor mode Oleksii Kurochko
2025-04-08 15:57 ` [PATCH v1 01/14] xen/riscv: implement get_s_time() Oleksii Kurochko
2025-04-10 12:52   ` Jan Beulich
2025-04-14 14:50     ` Oleksii Kurochko
2025-04-08 15:57 ` [PATCH v1 02/14] xen/riscv: introduce smp_clear_cpu_maps() Oleksii Kurochko
2025-04-10 13:10   ` Jan Beulich
2025-04-14 15:05     ` Oleksii Kurochko
2025-04-14 15:13       ` Jan Beulich
2025-04-08 15:57 ` [PATCH v1 03/14] xen/riscv: introduce ioremap() Oleksii Kurochko
2025-04-10 15:13   ` Jan Beulich
2025-04-15 10:29     ` Oleksii Kurochko
2025-04-15 11:02       ` Jan Beulich
2025-04-17 14:20         ` Oleksii Kurochko
2025-04-17 14:24           ` Jan Beulich
2025-04-17 14:37             ` Oleksii Kurochko
2025-04-17 14:49               ` Jan Beulich
2025-04-22  8:40                 ` Oleksii Kurochko
2025-04-22  9:14                   ` Jan Beulich
2025-04-24 13:30                     ` Oleksii Kurochko
2025-04-08 15:57 ` [PATCH v1 04/14] xen/riscv: introduce init_IRQ() Oleksii Kurochko
2025-04-10 15:25   ` Jan Beulich
2025-04-15 10:36     ` Oleksii Kurochko
2025-04-08 15:57 ` [PATCH v1 05/14] xen/riscv: introduce platform_get_irq() Oleksii Kurochko
2025-04-10 15:35   ` Jan Beulich
2025-04-15 11:11     ` Oleksii Kurochko
2025-04-15 11:23       ` Jan Beulich
2025-04-17 14:43         ` Oleksii Kurochko
2025-04-08 15:57 ` [PATCH v1 06/14] xen/riscv: riscv_of_processor_hartid() implementation Oleksii Kurochko
2025-04-10 15:53   ` Jan Beulich
2025-04-15 13:39     ` Oleksii Kurochko
2025-04-15 13:45       ` Jan Beulich
2025-04-25 17:07         ` Oleksii Kurochko
2025-04-28  6:31           ` Jan Beulich
2025-04-28 10:43             ` Oleksii Kurochko
2025-04-28 11:09               ` Jan Beulich
2025-04-08 15:57 ` [PATCH v1 07/14] xen/riscv: Introduce intc_hw_operations abstraction Oleksii Kurochko
2025-04-10 16:02   ` Jan Beulich
2025-04-15 15:01     ` Oleksii Kurochko
2025-04-08 15:57 ` [PATCH v1 08/14] xen/riscv: imsic_init() implementation Oleksii Kurochko
2025-04-14  9:32   ` Jan Beulich
2025-04-15 19:11     ` Oleksii Kurochko
     [not found]       ` <9a13c625-cd33-485d-a91f-9f005522b5a4@suse.com>
2025-04-23 11:44         ` Oleksii Kurochko
2025-04-29  8:24         ` Oleksii Kurochko
2025-04-08 15:57 ` [PATCH v1 09/14] xen/riscv: aplic_init() implementation Oleksii Kurochko
2025-04-14 10:04   ` Jan Beulich
2025-04-16 10:15     ` Oleksii Kurochko
2025-04-16 10:30       ` Jan Beulich
2025-04-17 15:21         ` Oleksii Kurochko
2025-04-17 15:30           ` Jan Beulich
2025-04-18 11:31             ` Oleksii Kurochko
2025-04-08 15:57 ` [PATCH v1 10/14] xen/riscv: implementation of aplic and imsic operations Oleksii Kurochko
2025-04-15 12:46   ` Jan Beulich
2025-04-16 19:05     ` Oleksii Kurochko
2025-04-17  6:25       ` Jan Beulich
2025-04-28  8:12         ` Oleksii Kurochko
2025-04-28  8:54           ` Jan Beulich
2025-04-30 16:07             ` Oleksii Kurochko
2025-04-15 14:53   ` Jan Beulich
2025-04-18 10:43     ` Oleksii Kurochko
2025-04-22  7:02       ` Jan Beulich
2025-04-25 19:31         ` Oleksii Kurochko
2025-04-28  6:35           ` Jan Beulich
2025-04-08 15:57 ` [PATCH v1 11/14] xen/riscv: add external interrupt handling for hypervisor mode Oleksii Kurochko
2025-04-15 14:42   ` Jan Beulich [this message]
2025-04-17  8:44     ` Oleksii Kurochko
2025-04-17  9:13       ` Oleksii Kurochko
2025-04-08 15:57 ` [PATCH v1 12/14] xen/riscv: implement setup_irq() Oleksii Kurochko
2025-04-15 15:55   ` Jan Beulich
2025-04-17 10:10     ` Oleksii Kurochko
2025-04-17 11:51       ` Jan Beulich
2025-04-08 15:57 ` [PATCH v1 13/14] xen/riscv: initialize interrupt controller Oleksii Kurochko
2025-04-15 15:59   ` Jan Beulich
2025-04-17 10:11     ` Oleksii Kurochko
2025-04-30 15:34       ` Oleksii Kurochko
2025-04-30 15:39         ` Jan Beulich
2025-04-08 15:57 ` [PATCH v1 14/14] xen/riscv: add basic UART support Oleksii Kurochko
2025-04-15 16:03   ` Jan Beulich
2025-04-17 10:31     ` Oleksii Kurochko
2025-04-17 11:52       ` Jan Beulich

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=a8a23afe-ae62-4b88-bf53-db2e1ada164d@suse.com \
    --to=jbeulich@suse.com \
    --cc=Romain.Caritey@microchip.com \
    --cc=alistair.francis@wdc.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=anthony.perard@vates.tech \
    --cc=bobbyeshleman@gmail.com \
    --cc=connojdavis@gmail.com \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --cc=oleksii.kurochko@gmail.com \
    --cc=roger.pau@citrix.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.