From: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
To: Mykola Kvach <xakep.amatop@gmail.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
Mirela Simonovic <mirela.simonovic@aggios.com>,
Stefano Stabellini <sstabellini@kernel.org>,
Julien Grall <julien@xen.org>,
Bertrand Marquis <bertrand.marquis@arm.com>,
Michal Orzel <michal.orzel@amd.com>,
Saeed Nowshadi <saeed.nowshadi@xilinx.com>,
Mykyta Poturai <Mykyta_Poturai@epam.com>,
Mykola Kvach <Mykola_Kvach@epam.com>
Subject: Re: [PATCH v5 02/12] xen/arm: gic-v2: Implement GIC suspend/resume functions
Date: Sat, 23 Aug 2025 00:01:16 +0000 [thread overview]
Message-ID: <878qjac3ec.fsf@epam.com> (raw)
In-Reply-To: <db677462d1b5b698db417182c05c3a6c3a17c0d0.1754943874.git.mykola_kvach@epam.com> (Mykola Kvach's message of "Mon, 11 Aug 2025 23:47:58 +0300")
Hi Mykola,
Mykola Kvach <xakep.amatop@gmail.com> writes:
> From: Mirela Simonovic <mirela.simonovic@aggios.com>
>
> System suspend may lead to a state where GIC would be powered down.
> Therefore, Xen should save/restore the context of GIC on suspend/resume.
>
> Note that the context consists of states of registers which are
> controlled by the hypervisor. Other GIC registers which are accessible
> by guests are saved/restored on context switch.
>
> Tested on Xilinx Ultrascale+ MPSoC with (and without) powering down
> the GIC.
I think you can drop this sentence, as I am pretty sure this patch
wasn't tested on Ultrascale+ for last five(?) years..
>
> Signed-off-by: Mirela Simonovic <mirela.simonovic@aggios.com>
> Signed-off-by: Saeed Nowshadi <saeed.nowshadi@xilinx.com>
> Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
> Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
> ---
> Changes in v4:
> - Add error logging for allocation failures
>
> Changes in v3:
> - Drop asserts and return error codes instead.
> - Wrap code with CONFIG_SYSTEM_SUSPEND.
>
> Changes in v2:
> - Minor fixes after review.
> ---
> xen/arch/arm/gic-v2.c | 154 +++++++++++++++++++++++++++++++++
> xen/arch/arm/gic.c | 29 +++++++
> xen/arch/arm/include/asm/gic.h | 12 +++
> 3 files changed, 195 insertions(+)
>
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index b23e72a3d0..dce8f5e924 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -1098,6 +1098,151 @@ static int gicv2_iomem_deny_access(struct domain *d)
> return iomem_deny_access(d, mfn, mfn + nr);
> }
>
> +#ifdef CONFIG_SYSTEM_SUSPEND
> +
> +/* GICv2 registers to be saved/restored on system suspend/resume */
> +struct gicv2_context {
> + /* GICC context */
> + uint32_t gicc_ctlr;
> + uint32_t gicc_pmr;
> + uint32_t gicc_bpr;
> + /* GICD context */
> + uint32_t gicd_ctlr;
> + uint32_t *gicd_isenabler;
> + uint32_t *gicd_isactiver;
> + uint32_t *gicd_ipriorityr;
> + uint32_t *gicd_itargetsr;
> + uint32_t *gicd_icfgr;
> +};
> +
> +static struct gicv2_context gicv2_context;
> +
> +static int gicv2_suspend(void)
> +{
> + unsigned int i;
> +
> + if ( !gicv2_context.gicd_isenabler )
> + {
> + dprintk(XENLOG_WARNING, "%s:%d: GICv2 suspend context not allocated!\n",
> + __func__, __LINE__);
Should this be ASSERT(gicv2_context.gicd_isenabler) ? Or do we expect
that this can happen during normal runtime?
Also, you don't need to print __func__ and __LINE__ as dprintk does this
for you already:
#define dprintk(lvl, fmt, args...) \
printk(lvl "%s:%d: " fmt, __FILE__, __LINE__, ## args)
> + return -ENOMEM;
> + }
> +
> + /* Save GICC configuration */
> + gicv2_context.gicc_ctlr = readl_gicc(GICC_CTLR);
> + gicv2_context.gicc_pmr = readl_gicc(GICC_PMR);
> + gicv2_context.gicc_bpr = readl_gicc(GICC_BPR);
> +
> + /* Save GICD configuration */
> + gicv2_context.gicd_ctlr = readl_gicd(GICD_CTLR);
> +
> + for ( i = 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 32); i++ )
> + gicv2_context.gicd_isenabler[i] = readl_gicd(GICD_ISENABLER + i * 4);
> +
> + for ( i = 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 32); i++ )
> + gicv2_context.gicd_isactiver[i] = readl_gicd(GICD_ISACTIVER + i * 4);
> +
I think you can merge this two loops
> + for ( i = 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 4); i++ )
> + gicv2_context.gicd_ipriorityr[i] = readl_gicd(GICD_IPRIORITYR + i * 4);
> +
> + for ( i = 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 4); i++ )
> + gicv2_context.gicd_itargetsr[i] = readl_gicd(GICD_ITARGETSR + i * 4);
> +
And this two as well
> + for ( i = 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 16); i++ )
> + gicv2_context.gicd_icfgr[i] = readl_gicd(GICD_ICFGR + i * 4);
> +
> + return 0;
> +}
> +
> +static void gicv2_resume(void)
> +{
> + unsigned int i;
> +
> + if ( !gicv2_context.gicd_isenabler )
> + {
> + dprintk(XENLOG_WARNING, "%s:%d: GICv2 suspend context not allocated!\n",
> + __func__, __LINE__);
the same comment as for gicv2_suspend(). Actually, we should not reach
here in any case.
> + return;
> + }
> +
> + gicv2_cpu_disable();
> + /* Disable distributor */
> + writel_gicd(0, GICD_CTLR);
> +
> + /* Restore GICD configuration */
> + for ( i = 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 32); i++ ) {
> + writel_gicd(0xffffffff, GICD_ICENABLER + i * 4);
> + writel_gicd(gicv2_context.gicd_isenabler[i], GICD_ISENABLER + i * 4);
> + }
> +
> + for ( i = 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 32); i++ ) {
> + writel_gicd(0xffffffff, GICD_ICACTIVER + i * 4);
> + writel_gicd(gicv2_context.gicd_isactiver[i], GICD_ISACTIVER + i * 4);
> + }
> +
> + for ( i = 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 4); i++ )
> + writel_gicd(gicv2_context.gicd_ipriorityr[i], GICD_IPRIORITYR + i * 4);
> +
> + for ( i = 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 4); i++ )
> + writel_gicd(gicv2_context.gicd_itargetsr[i], GICD_ITARGETSR + i * 4);
> +
> + for ( i = 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 16); i++ )
> + writel_gicd(gicv2_context.gicd_icfgr[i], GICD_ICFGR + i * 4);
> +
> + /* Make sure all registers are restored and enable distributor */
> + writel_gicd(gicv2_context.gicd_ctlr | GICD_CTL_ENABLE, GICD_CTLR);
> +
> + /* Restore GIC CPU interface configuration */
> + writel_gicc(gicv2_context.gicc_pmr, GICC_PMR);
> + writel_gicc(gicv2_context.gicc_bpr, GICC_BPR);
> +
> + /* Enable GIC CPU interface */
> + writel_gicc(gicv2_context.gicc_ctlr | GICC_CTL_ENABLE | GICC_CTL_EOI,
> + GICC_CTLR);
> +}
> +
> +static void gicv2_alloc_context(struct gicv2_context *gc)
> +{
> + uint32_t n = gicv2_info.nr_lines;
> +
> + gc->gicd_isenabler = xzalloc_array(uint32_t, DIV_ROUND_UP(n, 32));
> + if ( !gc->gicd_isenabler )
> + goto err_free;
> +
> + gc->gicd_isactiver = xzalloc_array(uint32_t, DIV_ROUND_UP(n, 32));
> + if ( !gc->gicd_isactiver )
> + goto err_free;
> +
> + gc->gicd_itargetsr = xzalloc_array(uint32_t, DIV_ROUND_UP(n, 4));
> + if ( !gc->gicd_itargetsr )
> + goto err_free;
> +
> + gc->gicd_ipriorityr = xzalloc_array(uint32_t, DIV_ROUND_UP(n, 4));
> + if ( !gc->gicd_ipriorityr )
> + goto err_free;
> +
> + gc->gicd_icfgr = xzalloc_array(uint32_t, DIV_ROUND_UP(n, 16));
> + if ( !gc->gicd_icfgr )
> + goto err_free;
> +
> + return;
> +
> + err_free:
> + dprintk(XENLOG_ERR,
> + "%s:%d: failed to allocate memory for GICv2 suspend context\n",
> + __func__, __LINE__);
Okay, this partially answers to my previous question about memory
allocation. So it is possible to have active system without space for
GIC context... But this basically renders system un-suspendable. I think
this warrants non-debug print to warn user that suspend will be not
available.
[...]
--
WBR, Volodymyr
next prev parent reply other threads:[~2025-08-23 0:01 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-11 20:47 [PATCH v5 00/12] Add initial Xen Suspend-to-RAM support on ARM64 Mykola Kvach
2025-08-11 20:47 ` [PATCH v5 01/12] xen/arm: Add suspend and resume timer helpers Mykola Kvach
2025-08-11 20:47 ` [PATCH v5 02/12] xen/arm: gic-v2: Implement GIC suspend/resume functions Mykola Kvach
2025-08-23 0:01 ` Volodymyr Babchuk [this message]
2025-08-26 13:41 ` Mykola Kvach
2025-08-11 20:47 ` [PATCH v5 03/12] xen/arm: gic-v3: Implement GICv3 " Mykola Kvach
2025-08-23 0:20 ` Volodymyr Babchuk
2025-08-26 13:41 ` Mykola Kvach
2025-08-11 20:48 ` [PATCH v5 04/12] xen/arm: Prevent crash during disable_nonboot_cpus on suspend Mykola Kvach
2025-08-23 0:36 ` Volodymyr Babchuk
2025-08-26 13:42 ` Mykola Kvach
2025-08-11 20:48 ` [PATCH v5 05/12] xen/arm: irq: avoid local IRQ descriptors reinit on system resume Mykola Kvach
2025-08-23 0:37 ` Volodymyr Babchuk
2025-08-11 20:48 ` [PATCH v5 06/12] xen/arm: irq: Restore state of local IRQs during " Mykola Kvach
2025-08-23 0:45 ` Volodymyr Babchuk
2025-08-26 13:42 ` Mykola Kvach
2025-08-11 20:48 ` [PATCH v5 07/12] xen/arm: Add support for system suspend triggered by hardware domain Mykola Kvach
2025-08-12 7:18 ` Jan Beulich
2025-08-23 0:53 ` Volodymyr Babchuk
2025-08-23 1:00 ` Volodymyr Babchuk
2025-08-26 13:42 ` Mykola Kvach
2025-08-11 20:48 ` [PATCH v5 08/12] xen/arm: Implement PSCI SYSTEM_SUSPEND call (host interface) Mykola Kvach
2025-08-23 1:06 ` Volodymyr Babchuk
2025-08-26 13:42 ` Mykola Kvach
2025-08-11 20:48 ` [PATCH v5 09/12] xen/arm: Resume memory management on Xen resume Mykola Kvach
2025-08-11 20:48 ` [PATCH v5 10/12] xen/arm: Save/restore context on suspend/resume Mykola Kvach
2025-08-23 17:34 ` Volodymyr Babchuk
2025-08-26 13:42 ` Mykola Kvach
2025-08-11 20:48 ` [PATCH v5 11/12] iommu/ipmmu-vmsa: Implement suspend/resume callbacks Mykola Kvach
2025-08-23 17:48 ` Volodymyr Babchuk
2025-08-26 13:42 ` Mykola Kvach
2025-08-11 20:48 ` [PATCH v5 12/12] xen/arm: Suspend/resume IOMMU on Xen suspend/resume Mykola Kvach
2025-08-23 17:54 ` Volodymyr Babchuk
2025-08-26 13:42 ` Mykola Kvach
2025-08-26 15:01 ` Oleksandr Tyshchenko
2025-08-26 16:17 ` Mykola Kvach
2025-08-11 21:53 ` [PATCH v5 00/12] Add initial Xen Suspend-to-RAM support on ARM64 Julien Grall
2025-08-12 4:58 ` Mykola Kvach
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=878qjac3ec.fsf@epam.com \
--to=volodymyr_babchuk@epam.com \
--cc=Mykola_Kvach@epam.com \
--cc=Mykyta_Poturai@epam.com \
--cc=bertrand.marquis@arm.com \
--cc=julien@xen.org \
--cc=michal.orzel@amd.com \
--cc=mirela.simonovic@aggios.com \
--cc=saeed.nowshadi@xilinx.com \
--cc=sstabellini@kernel.org \
--cc=xakep.amatop@gmail.com \
--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.