All of lore.kernel.org
 help / color / mirror / Atom feed
From: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
To: Leonid Komarianskyi <Leonid_Komarianskyi@epam.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"olekstysh@gmail.com" <olekstysh@gmail.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>
Subject: Re: [PATCH v6 04/12] xen/arm/irq: add handling for IRQs in the eSPI range
Date: Wed, 3 Sep 2025 20:56:22 +0000	[thread overview]
Message-ID: <87a53buufe.fsf@epam.com> (raw)
In-Reply-To: <bdaec9b9704a6f21325b507365a165cce89cca16.1756908472.git.leonid_komarianskyi@epam.com> (Leonid Komarianskyi's message of "Wed, 3 Sep 2025 14:29:59 +0000")

Hi Leonid,

Leonid Komarianskyi <Leonid_Komarianskyi@epam.com> writes:

> Currently, Xen does not support eSPI interrupts, leading
> to a data abort when such interrupts are defined in the DTS.
>
> This patch introduces a separate array to initialize up to
> 1024 interrupt descriptors in the eSPI range and adds the
> necessary defines and helper function. These changes lay the
> groundwork for future implementation of full eSPI interrupt
> support. As this GICv3.1 feature is not required by all vendors,
> all changes are guarded by ifdefs, depending on the corresponding
> Kconfig option.
>
> Signed-off-by: Leonid Komarianskyi <leonid_komarianskyi@epam.com>
>
> ---
> Changes in V6:
> - added an assert in is_espi() when CONFIG_GICV3_ESPI=n to ensure that
>   out-of-range array resources are not accessed, e.g., in __irq_to_desc()
> - removed unnecessary parentheses in is_espi()
> - converted helper macro to inline functions and added sanity checks
>   with ASSERTs to them
> - defined espi_to_desc for non-eSPI builds as a prototype
> - updates the comments
> - used the IS_ENABLED(CONFIG_GICV3_ESPI) macro to initialize nr_irqs
>
> Changes in V5:
> - no functional changes introduced by this version compared with V4, only
>   minor fixes and removal of ifdefs for macroses
> - added TODO comment, suggested by Oleksandr Tyshchenko
> - changed int to unsigned int for irqs
> - removed ifdefs for eSPI-specific defines and macros to reduce the
>   number of ifdefs and code duplication in further changes
> - removed reviewed-by as moving defines from ifdefs requires additional
>   confirmation from reviewers
>
> Changes in V4:
> - removed redundant line with 'default n' in Kconfig, as it is disabled
>   by default, without explicit specification
> - added reviewed-by from Volodymyr Babchuk
>
> Changes in V3:
> - introduced a new define NR_ESPI_IRQS to avoid confusion, like in the
>   case of using NR_IRQS for espi_desc array
> - implemented helper functions espi_to_desc and init_espi_data to make
>   it possible to add stubs with the same name, and as a result, reduce
>   the number of #ifdefs
> - disable CONFIG_GICV3_ESPI default value to n
>
> Changes in V2:
> - use (ESPI_MAX_INTID + 1) instead of (ESPI_BASE_INTID + NR_IRQS)
> - remove unnecessary comment for nr_irqs initialization
> ---
>  xen/arch/arm/Kconfig           |  8 +++++
>  xen/arch/arm/include/asm/irq.h | 37 ++++++++++++++++++++++++
>  xen/arch/arm/irq.c             | 53 ++++++++++++++++++++++++++++++++--
>  3 files changed, 96 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index 17df147b25..43b05533b1 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -135,6 +135,14 @@ config GICV3
>  	  Driver for the ARM Generic Interrupt Controller v3.
>  	  If unsure, use the default setting.
>  
> +config GICV3_ESPI
> +	bool "Extended SPI range support"
> +	depends on GICV3 && !NEW_VGIC
> +	help
> +	  Allow Xen and domains to use interrupt numbers from the extended SPI
> +	  range, from 4096 to 5119. This feature is introduced in GICv3.1
> +	  architecture.
> +
>  config HAS_ITS
>          bool "GICv3 ITS MSI controller support (UNSUPPORTED)" if UNSUPPORTED
>          depends on GICV3 && !NEW_VGIC && !ARM_32
> diff --git a/xen/arch/arm/include/asm/irq.h b/xen/arch/arm/include/asm/irq.h
> index 5bc6475eb4..f4d0997651 100644
> --- a/xen/arch/arm/include/asm/irq.h
> +++ b/xen/arch/arm/include/asm/irq.h
> @@ -32,6 +32,10 @@ struct arch_irq_desc {
>  #define SPI_MAX_INTID   1019
>  #define LPI_OFFSET      8192
>  
> +#define ESPI_BASE_INTID 4096
> +#define ESPI_MAX_INTID  5119
> +#define NR_ESPI_IRQS    1024
> +
>  /* LPIs are always numbered starting at 8192, so 0 is a good invalid case. */
>  #define INVALID_LPI     0
>  
> @@ -39,7 +43,12 @@ struct arch_irq_desc {
>  #define INVALID_IRQ     1023
>  
>  extern const unsigned int nr_irqs;
> +#ifdef CONFIG_GICV3_ESPI
> +/* This will cover the eSPI range, to allow asignmant of eSPIs to domains. */
> +#define nr_static_irqs (ESPI_MAX_INTID + 1)
> +#else
>  #define nr_static_irqs NR_IRQS
> +#endif
>  
>  struct irq_desc;
>  struct irqaction;
> @@ -55,6 +64,34 @@ static inline bool is_lpi(unsigned int irq)
>      return irq >= LPI_OFFSET;
>  }
>  
> +static inline unsigned int espi_intid_to_idx(unsigned int intid)
> +{
> +    ASSERT(intid >= ESPI_BASE_INTID && intid <= ESPI_MAX_INTID);
> +    return intid - ESPI_BASE_INTID;
> +}
> +
> +static inline unsigned int espi_idx_to_intid(unsigned int idx)
> +{
> +    ASSERT(idx <= NR_ESPI_IRQS);
> +    return idx + ESPI_BASE_INTID;
> +}
> +
> +static inline bool is_espi(unsigned int irq)
> +{
> +#ifdef CONFIG_GICV3_ESPI
> +    return irq >= ESPI_BASE_INTID && irq <= ESPI_MAX_INTID;
> +#else
> +    /*
> +     * The function should not be called for eSPIs when CONFIG_GICV3_ESPI is
> +     * disabled. Returning false allows the compiler to optimize the code
> +     * when the config is disabled, while the assert ensures that out-of-range
> +     * array resources are not accessed, e.g., in __irq_to_desc().
> +     */
> +    ASSERT(irq >= ESPI_BASE_INTID);

This really puzzles me. Should it be other way around? I.e.

ASSERT(irq < ESPI_BASE_INTID) ? Or even ASSERT(irq <= 1022) ?

Actually, I tried to your series. XEN does not boots at all when
CONFIG_GICV3_ESPI=n. Looks like it panics even before it can bring up
the console, as I don't see any prints in QEMU. Non-debug build boots
fine, thought, but this is expected, as ASSERTs are disabled.


> +    return false;
> +#endif
> +}
> +
>  #define domain_pirq_to_irq(d, pirq) (pirq)
>  
>  bool is_assignable_irq(unsigned int irq);
> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
> index b8eccfc924..c934d39bf6 100644
> --- a/xen/arch/arm/irq.c
> +++ b/xen/arch/arm/irq.c
> @@ -19,7 +19,9 @@
>  #include <asm/gic.h>
>  #include <asm/vgic.h>
>  
> -const unsigned int nr_irqs = NR_IRQS;
> +const unsigned int nr_irqs = IS_ENABLED(CONFIG_GICV3_ESPI) ?
> +                                        (ESPI_MAX_INTID + 1) :
> +                                        NR_IRQS;
>  
>  static unsigned int local_irqs_type[NR_LOCAL_IRQS];
>  static DEFINE_SPINLOCK(local_irqs_type_lock);
> @@ -46,6 +48,50 @@ void irq_end_none(struct irq_desc *irq)
>  }
>  
>  static irq_desc_t irq_desc[NR_IRQS - NR_LOCAL_IRQS];
> +#ifdef CONFIG_GICV3_ESPI
> +/* TODO: Consider allocating an array dynamically */

I'd considered using radix tree, honestly... But this is just topic for
discussion, no action should be taken here.

> +static irq_desc_t espi_desc[NR_ESPI_IRQS];
> +
> +static struct irq_desc *espi_to_desc(unsigned int irq)
> +{
> +    return &espi_desc[espi_intid_to_idx(irq)];
> +}
> +
> +static int __init init_espi_data(void)
> +{
> +    unsigned int irq;
> +
> +    for ( irq = ESPI_BASE_INTID; irq <= ESPI_MAX_INTID; irq++ )
> +    {
> +        struct irq_desc *desc = irq_to_desc(irq);
> +        int rc = init_one_irq_desc(desc);
> +
> +        if ( rc )
> +            return rc;
> +
> +        desc->irq = irq;
> +        desc->action  = NULL;
> +    }
> +
> +    return 0;
> +}
> +#else
> +/*
> + * Defined as a prototype as it should not be called if CONFIG_GICV3_ESPI=n.
> + * Without CONFIG_GICV3_ESPI, the additional 1024 IRQ descriptors will not
> + * be defined, and thus, they cannot be used. Unless INTIDs from the eSPI
> + * range are mistakenly defined in Xen DTS when the appropriate config is
> + * disabled, this function will not be reached because is_espi will return
> + * false for non-eSPI INTIDs.
> + */
> +struct irq_desc *espi_to_desc(unsigned int irq);
> +
> +static int __init init_espi_data(void)
> +{
> +    return 0;
> +}
> +#endif
> +
>  static DEFINE_PER_CPU(irq_desc_t[NR_LOCAL_IRQS], local_irq_desc);
>  
>  struct irq_desc *__irq_to_desc(unsigned int irq)
> @@ -53,6 +99,9 @@ struct irq_desc *__irq_to_desc(unsigned int irq)
>      if ( irq < NR_LOCAL_IRQS )
>          return &this_cpu(local_irq_desc)[irq];
>  
> +    if ( is_espi(irq) )
> +        return espi_to_desc(irq);
> +
>      return &irq_desc[irq-NR_LOCAL_IRQS];
>  }
>  
> @@ -79,7 +128,7 @@ static int __init init_irq_data(void)
>          desc->action  = NULL;
>      }
>  
> -    return 0;
> +    return init_espi_data();
>  }
>  
>  static int init_local_irq_data(unsigned int cpu)

-- 
WBR, Volodymyr

  reply	other threads:[~2025-09-03 20:57 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-03 14:29 [PATCH v6 00/12] Introduce eSPI support Leonid Komarianskyi
2025-09-03 14:29 ` [PATCH v6 01/12] xen/arm: gicv3: refactor obtaining GIC addresses for common operations Leonid Komarianskyi
2025-09-03 14:29 ` [PATCH v6 02/12] xen/arm: gic: implement helper functions for INTID checks Leonid Komarianskyi
2025-09-03 14:29 ` [PATCH v6 03/12] xen/arm: vgic: implement helper functions for virq checks Leonid Komarianskyi
2025-09-03 14:29 ` [PATCH v6 04/12] xen/arm/irq: add handling for IRQs in the eSPI range Leonid Komarianskyi
2025-09-03 20:56   ` Volodymyr Babchuk [this message]
2025-09-03 21:16     ` Leonid Komarianskyi
2025-09-04 12:27   ` Julien Grall
2025-09-04 13:09     ` Leonid Komarianskyi
2025-09-04 14:06       ` Julien Grall
2025-09-04 17:34         ` Leonid Komarianskyi
2025-09-03 14:30 ` [PATCH v6 05/12] xen/arm: gicv3: implement handling of GICv3.1 eSPI Leonid Komarianskyi
2025-09-04 14:37   ` Oleksandr Tyshchenko
2025-09-04 15:10     ` Leonid Komarianskyi
2025-09-04 15:34       ` Oleksandr Tyshchenko
2025-09-03 14:30 ` [PATCH v6 06/12] xen/arm/irq: allow eSPI processing in the gic_interrupt function Leonid Komarianskyi
2025-09-03 14:30 ` [PATCH v6 07/12] xen/arm: gicv3: modify ICH_LR_PHYSICAL_MASK to allow eSPI processing Leonid Komarianskyi
2025-09-03 20:58   ` Volodymyr Babchuk
2025-09-03 14:30 ` [PATCH v6 08/12] xen/arm: vgic: add resource management for extended SPIs Leonid Komarianskyi
2025-09-03 21:24   ` Volodymyr Babchuk
2025-09-04  6:20     ` Leonid Komarianskyi
2025-09-04 18:12   ` Oleksandr Tyshchenko
2025-09-04 18:23     ` Leonid Komarianskyi
2025-09-03 14:30 ` [PATCH v6 09/12] xen/arm: domain_build/dom0less-build: adjust domains config to support eSPIs Leonid Komarianskyi
2025-09-03 14:30 ` [PATCH v6 10/12] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI registers Leonid Komarianskyi
2025-09-03 19:27   ` Oleksandr Tyshchenko
2025-09-03 21:37     ` Volodymyr Babchuk
2025-09-03 23:04       ` Julien Grall
2025-09-04  5:52         ` Leonid Komarianskyi
2025-09-04 11:17           ` Oleksandr Tyshchenko
2025-09-04 10:49       ` Oleksandr Tyshchenko
2025-09-04  6:15     ` Leonid Komarianskyi
2025-09-03 14:30 ` [PATCH v6 11/12] doc/man: update description for nr_spis with eSPI Leonid Komarianskyi
2025-09-03 14:30 ` [PATCH v6 12/12] CHANGELOG.md: add mention of GICv3.1 eSPI support Leonid Komarianskyi

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=87a53buufe.fsf@epam.com \
    --to=volodymyr_babchuk@epam.com \
    --cc=Leonid_Komarianskyi@epam.com \
    --cc=bertrand.marquis@arm.com \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --cc=olekstysh@gmail.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.