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 v3 09/11] xen/arm: domain_build/dom0less-build: adjust domains config to support eSPIs
Date: Tue, 26 Aug 2025 23:08:46 +0000 [thread overview]
Message-ID: <874itt4r5t.fsf@epam.com> (raw)
In-Reply-To: <bff3d1c4302e8780771abed42f624cafe76776cd.1756216943.git.leonid_komarianskyi@epam.com> (Leonid Komarianskyi's message of "Tue, 26 Aug 2025 14:05:38 +0000")
Hi Leonid,
Leonid Komarianskyi <Leonid_Komarianskyi@epam.com> writes:
> The Dom0 and DomUs logic for the dom0less configuration in create_dom0()
> and arch_create_domUs() has been updated to account for extended SPIs
> when supported by the hardware and enabled with CONFIG_GICV3_ESPI. These
> changes ensure the proper calculation of the maximum number of SPIs and
> eSPIs available to Dom0 and DomUs in dom0less setups.
>
> When eSPIs are supported by the hardware and CONFIG_GICV3_ESPI is
> enabled, the maximum number of eSPI interrupts is calculated using the
> ESPI_BASE_INTID offset (4096) and is limited to 1024, with 32 IRQs
> subtracted. To ensure compatibility with DomUs (Dom0 setups) domains,
> where this adjustment is applied by the toolstack during domain
> creation, while for Dom0 or DomUs in Dom0, it is handled directly during
> VGIC initialization. If eSPIs are not supported, the calculation
> defaults to using the standard SPI range, with a maximum value of
> 960 interrupt lines, as it works currently.
>
> Signed-off-by: Leonid Komarianskyi <leonid_komarianskyi@epam.com>
>
> ---
> Changes in V2:
> - no changes
>
> Changes in V3:
> - renamed macro VGIC_DEF_NR_ESPIS to more appropriate VGIC_DEF_MAX_SPI
Will VGIC_DEF_MAX_ESPI be better? When other code refer to "SPI" it mean
"common SPI" (less than 1022), while ESPI is used for extended SPI. So,
naturally it feels that VGIC_DEF_MAX_SPI should be equal to 1022...
> - added eSPI initialization for dom0less setups
> - fixed comment with mentions about dom0less builds
> - fixed formatting for lines with more than 80 symbols
> - updated commit message
> ---
> xen/arch/arm/dom0less-build.c | 12 ++++++++++++
> xen/arch/arm/domain_build.c | 11 +++++++++++
> xen/arch/arm/include/asm/vgic.h | 14 ++++++++++++++
> 3 files changed, 37 insertions(+)
>
> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
> index 69b9ea22ce..f4f9077db5 100644
> --- a/xen/arch/arm/dom0less-build.c
> +++ b/xen/arch/arm/dom0less-build.c
> @@ -286,6 +286,18 @@ void __init arch_create_domUs(struct dt_device_node *node,
> int vpl011_virq = GUEST_VPL011_SPI;
>
> d_cfg->arch.nr_spis = VGIC_DEF_NR_SPIS;
> +#ifdef CONFIG_GICV3_ESPI
> + /*
> + * Check if the hardware supports extended SPIs (even if the
> + * appropriate config is set). If not, the common SPI range
> + * will be used. Otherwise overwrite the nr_spis with the maximum
> + * available INTID from eSPI range. In that case, the number of
> + * regular SPIs will be adjusted to the maximum value during vGIC
> + * initialization.
> + */
> + if ( gic_number_espis() > 0 )
> + d_cfg->arch.nr_spis = VGIC_DEF_MAX_SPI;
> +#endif
>
> /*
> * The VPL011 virq is GUEST_VPL011_SPI, unless direct-map is
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index d91a71acfd..148a8bdb60 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -2055,6 +2055,17 @@ void __init create_dom0(void)
> /* The vGIC for DOM0 is exactly emulating the hardware GIC */
> dom0_cfg.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE;
> dom0_cfg.arch.nr_spis = VGIC_DEF_NR_SPIS;
> +#ifdef CONFIG_GICV3_ESPI
> + /*
> + * Check if the hardware supports extended SPIs (even if the appropriate
> + * config is set). If not, the common SPI range will be used. Otherwise
> + * overwrite the nr_spis with the maximum available INTID from eSPI range.
> + * In that case, the number of regular SPIs will be adjusted to the maximum
> + * value during vGIC initialization.
> + */
> + if ( gic_number_espis() > 0 )
> + dom0_cfg.arch.nr_spis = VGIC_DEF_MAX_SPI;
> +#endif
> dom0_cfg.arch.tee_type = tee_get_type();
> dom0_cfg.max_vcpus = dom0_max_vcpus();
>
> diff --git a/xen/arch/arm/include/asm/vgic.h b/xen/arch/arm/include/asm/vgic.h
> index 248b5869e1..0bb025f5d5 100644
> --- a/xen/arch/arm/include/asm/vgic.h
> +++ b/xen/arch/arm/include/asm/vgic.h
> @@ -353,6 +353,20 @@ extern void vgic_check_inflight_irqs_pending(struct vcpu *v,
> /* Default number of vGIC SPIs. 32 are substracted to cover local IRQs. */
> #define VGIC_DEF_NR_SPIS (min(gic_number_lines(), VGIC_MAX_IRQS) - 32)
>
> +#ifdef CONFIG_GICV3_ESPI
> +/*
> + * Returns the maximum eSPI INTID, supported by HW GIC, subtracted by 32. For
> + * non-Dom0 domains, the toolstack or arch_create_domUs function applies the
> + * same adjustment to cover local IRQs (please, see comment for macro that is
> + * used for regular SPIs - VGIC_DEF_NR_SPIS). We will add back this value
> + * during VGIC initialization. This ensures consistent handling for Dom0 and
> + * other domains. For the regular SPI range interrupts in this case, the
> + * maximum value of VGIC_DEF_NR_SPIS will be used.
> + */
> +#define VGIC_DEF_MAX_SPI (ESPI_BASE_INTID + \
> + min(gic_number_espis(), 1024U) - 32)
> +#endif
> +
> extern bool vgic_is_valid_line(struct domain *d, unsigned int virq);
>
> static inline bool vgic_is_spi(struct domain *d, unsigned int virq)
--
WBR, Volodymyr
next prev parent reply other threads:[~2025-08-26 23:09 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-26 14:05 [PATCH v3 00/11] Subject: [PATCH v3 00/11] Introduce eSPI support Leonid Komarianskyi
2025-08-26 14:05 ` [PATCH v3 02/11] xen/arm: gic: implement helper functions for INTID checks Leonid Komarianskyi
2025-08-26 19:49 ` Volodymyr Babchuk
2025-08-26 19:53 ` Volodymyr Babchuk
2025-08-26 14:05 ` [PATCH v3 01/11] xen/arm: gicv3: refactor obtaining GIC addresses for common operations Leonid Komarianskyi
2025-08-26 19:47 ` Volodymyr Babchuk
2025-08-26 14:05 ` [PATCH v3 03/11] xen/arm: vgic: implement helper functions for virq checks Leonid Komarianskyi
2025-08-26 20:02 ` Volodymyr Babchuk
2025-08-27 8:25 ` Leonid Komarianskyi
2025-08-26 14:05 ` [PATCH v3 06/11] xen/arm/irq: allow eSPI processing in the do_IRQ function Leonid Komarianskyi
2025-08-26 22:30 ` Volodymyr Babchuk
2025-08-27 10:00 ` Leonid Komarianskyi
2025-08-26 14:05 ` [PATCH v3 05/11] xen/arm: gicv3: implement handling of GICv3.1 eSPI Leonid Komarianskyi
2025-08-26 22:25 ` Volodymyr Babchuk
2025-08-27 9:56 ` Leonid Komarianskyi
2025-08-27 10:25 ` Oleksandr Tyshchenko
2025-08-27 13:38 ` Leonid Komarianskyi
2025-08-27 13:57 ` Oleksandr Tyshchenko
2025-08-26 14:05 ` [PATCH v3 04/11] xen/arm/irq: add handling for IRQs in the eSPI range Leonid Komarianskyi
2025-08-26 20:16 ` Volodymyr Babchuk
2025-08-27 6:35 ` Oleksandr Tyshchenko
2025-08-27 13:22 ` Leonid Komarianskyi
2025-08-26 14:05 ` [PATCH v3 08/11] xen/arm: vgic: add resource management for extended SPIs Leonid Komarianskyi
2025-08-26 23:00 ` Volodymyr Babchuk
2025-08-27 10:11 ` Leonid Komarianskyi
2025-08-26 14:05 ` [PATCH v3 07/11] xen/arm: gicv3: modify ICH_LR_PHYSICAL_MASK to allow eSPI processing Leonid Komarianskyi
2025-08-26 22:40 ` Volodymyr Babchuk
2025-08-26 14:05 ` [PATCH v3 09/11] xen/arm: domain_build/dom0less-build: adjust domains config to support eSPIs Leonid Komarianskyi
2025-08-26 23:08 ` Volodymyr Babchuk [this message]
2025-08-27 10:25 ` Leonid Komarianskyi
2025-08-27 12:01 ` Oleksandr Tyshchenko
2025-08-27 13:47 ` Leonid Komarianskyi
2025-08-27 15:01 ` Leonid Komarianskyi
2025-08-26 14:05 ` [PATCH v3 10/11] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI registers Leonid Komarianskyi
2025-08-26 19:57 ` Oleksandr Tyshchenko
2025-08-27 11:13 ` Leonid Komarianskyi
2025-08-27 13:44 ` Oleksandr Tyshchenko
2025-08-27 14:41 ` Leonid Komarianskyi
2025-08-26 14:05 ` [PATCH v3 11/11] CHANGELOG.md: add mention of GICv3.1 eSPI support Leonid Komarianskyi
2025-08-28 13:37 ` Oleksii Kurochko
2025-08-28 16:45 ` 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=874itt4r5t.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.