Re: [PATCH] xen/arm: gic-v2: disable interrupt bypass on CPU shutdown

[Mykola Kvach <xakep.amatop@xxxxxxxxx>]

Hi Luca,

Thank you for the review.


On Mon, Apr 20, 2026 at 2:42 PM Luca Fancellu <Luca.Fancellu@xxxxxxx> wrote:
>
> Hi Mykola,
>
> > On 10 Apr 2026, at 10:36, Mykola Kvach <xakep.amatop@xxxxxxxxx> wrote:
> >
> > From: Mykola Kvach <mykola_kvach@xxxxxxxx>
> >
> > The GICv2 CPU shutdown path currently writes 0 to GICC_CTLR.
> >
> > Per IHI0048B.b section 2.3.1, clearing IRQBypDisGrp{0,1} and
> > FIQBypDisGrp{0,1} selects bypass rather than deasserted interrupt
> > outputs when the CPU interface stops driving them. Tables 2-2 and 2-3
> > show that a zeroed GICC_CTLR can fall back to the legacy IRQ/FIQ inputs
> > instead of fully disabling the interface.
> >
> > Fix this by reading GICC_CTLR, setting the bypass-disable bits, and
> > clearing both group-enable bits before writing the value back. Keep the
> > existing GICC_CTL_ENABLE definition for the init path and use a separate
> > mask for the shutdown-side group-enable handling.
> >
> > Section 2.3.2 also states that wakeup event signals remain available
> > even when both GIC interrupt signaling and interrupt bypass are
> > disabled, so disabling bypass does not break the power-management use
> > case, i.e. suspend modes.
> >
> > Fixes: 5e40a1b4351e ("arm: SMP CPU shutdown")
> > Signed-off-by: Mykola Kvach <mykola_kvach@xxxxxxxx>
> > ---
> > xen/arch/arm/gic-v2.c          |  7 ++++++-
> > xen/arch/arm/include/asm/gic.h | 21 +++++++++++++++++++--
> > 2 files changed, 25 insertions(+), 3 deletions(-)
> >
> > diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> > index b23e72a3d0..22aa25bad0 100644
> > --- a/xen/arch/arm/gic-v2.c
> > +++ b/xen/arch/arm/gic-v2.c
> > @@ -408,7 +408,12 @@ static void gicv2_cpu_init(void)
> >
> > static void gicv2_cpu_disable(void)
> > {
> > -    writel_gicc(0x0, GICC_CTLR);
> > +    uint32_t ctlr = readl_gicc(GICC_CTLR);
> > +
> > +    ctlr |= GICC_CTL_BYP_DIS_MASK;
>
> If the GIC v2 implementation includes the Security Extensions, the bit 7-8
> are reserved, but now we are unconditionally writing on them.

You are right.

I had assumed that, since these bits are reserved in that view, writing
them would be harmless. However, the specification does not say that
they are WI, so this is not something the patch should rely on.

Looking at it again, there may be a similar layout-dependent issue in
cpu_init() as well, since the current write there also forces all other
bits to zero apart from the ones explicitly set.

I will rework this patch accordingly so that cpu_disable() only updates
the bits that are architecturally defined for the current GICC_CTLR
layout, and I will take another look at the init path separately.


Best regards,
Mykola

>
> Cheers,
> Luca
>