Re: [PATCH for-4.22 v2.5] xen/arm: gic: defer host LPI allocation until after ITS init

[Mykola Kvach <xakep.amatop@xxxxxxxxx>]

Hi Julien, Oleksii,

On Fri, Jun 19, 2026 at 2:52 PM Julien Grall <julien@xxxxxxx> wrote:
>
>
>
> On 19/06/2026 12:34, Orzel, Michal wrote:
> >
> >
> > On 19-Jun-26 13:23, Julien Grall wrote:
> >> Hi Michal,
> >>
> >> On 19/06/2026 10:48, Orzel, Michal wrote:
> >>> @Oleksii, can we ask for a release ack here?
> >>
> >> Can you explain the pros/cons of introducing this patch quite late?
> > The advantage is that it fixes the broken LPIs on affected hardware.
>
>  > The disadvantage is the reordering risk but I don't think there is
> any issue.
>
> See more below.
> >>
> >> One of the risk here is that we are now initializing the LPIs *after*
> >> the ITSes. I understand this is because we want to know the workaround.
> >> However, I vaguely recall that there was a dependency in the
> >> configuration. So are we confident the new ordering will not bring other
> >> issues? Ideally this should have been explained in the commit message.
> > gic-v3-its.c never references host LPI state, so ITS init has no dependency 
> > on LPIs.
>
> My concern is at the HW level. The ITS is using LPIs. But we will
> configure the ITS first and then the LPIs.
>
> What probaly saves us is the fact gicv3_lpi_init_host_lpis() only seem
> to allocate memory. This is a bit fragile though.

Regarding the ordering concern, the only operation moved by this patch
is gicv3_lpi_init_host_lpis(). It does not program either the
Redistributor or the ITS. It initializes Xen-side host LPI bookkeeping,
registers the CPU notifier, and allocates the boot CPU pending table.

gicv3_its_init() programs the ITS tables and command queue and enables
the ITS, but Xen does not enqueue any ITS command there. The first
MAPC/SYNC commands are issued by gicv3_its_setup_collection().

The relevant hardware-visible sequence in gicv3_cpu_init() therefore
remains:

    gicv3_lpi_init_rdist()       /* program PENDBASER/PROPBASER */
    gicv3_enable_lpis()          /* set EnableLPIs, followed by wmb() */
    gicv3_its_setup_collection() /* issue MAPC/SYNC */

So the ordering introduced by 95604873cc is preserved: no MAPC command
is submitted before GICR_PENDBASER/GICR_PROPBASER have been programmed
and the write setting GICR_CTLR.EnableLPIs has been made visible.

This matches the relevant architectural requirement: while
GICR_CTLR.EnableLPIs is 0, ITS translation requests or commands
involving LPIs in that Redistributor are ignored. This patch changes
when the backing memory is allocated, not when the Redistributor is
programmed or when the first ITS command is submitted.

The benefit of taking this for 4.22 is that it fixes broken LPIs on
systems where an ITS workaround changes the required memory attributes.
The ordering-specific fragility is that this reasoning relies on
gicv3_lpi_init_host_lpis() remaining allocation/bookkeeping-only. I
agree that this implicit dependency should be documented explicitly.

I will respin the commit message to describe this ordering and explain
why the hardware-visible sequence is unchanged.

Does this address your concern about taking the fix for 4.22?

Best regards,
Mykola