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,

Thanks.

On Fri, Jun 19, 2026 at 8:23 PM Julien Grall <julien@xxxxxxx> wrote:
>
> Hi,
>
> On 19/06/2026 15:55, Mykola Kvach wrote:
> > 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?
>
> Thanks for the detailed explanation. As I wrote back to Oleksii, I think
> the code could be re-architecture post-4.22.

For post-4.22, I agree with the proposed restructuring. I will take it
into account when updating the follow-up quirk series, so that all ITS
workarounds are queried before host LPI initialization and ITS
activation.

>
> For 4.22, no need to send a new patch. You could propose a new commit
> message here and we update on merge.

For 4.22, I propose the following commit message:

xen/arm: gic: defer host LPI allocation until after ITS init

gicv3_lpi_init_host_lpis() initializes Xen-side host LPI bookkeeping,
registers the CPU notifier, and allocates the boot CPU pending table.
The pending table allocation uses gicv3_its_get_memflags().

ITS quirks are discovered by gicv3_its_init(), so allocating the boot
CPU pending table from gicv3_dist_init() can happen before the memory
restrictions required by the ITS are known. On affected systems this
can leave the pending table allocated using the default memory policy.

Move host LPI initialization after gicv3_its_init(), and only run it
when a host ITS was found. The old call ignored the return value. Now
that the call is made from gicv3_init(), check it and panic on failure
because Redistributor LPI initialization relies on that state being
available.

Although this reorders host LPI bookkeeping with respect to ITS
initialization, it does not change the hardware-visible LPI setup
sequence. gicv3_lpi_init_host_lpis() does not program the
Redistributor or submit any ITS commands. gicv3_cpu_init() still
programs GICR_PENDBASER/GICR_PROPBASER via
gicv3_lpi_init_rdist(), sets GICR_CTLR.EnableLPIs, and only then calls
gicv3_its_setup_collection(), which submits the first MAPC/SYNC
commands. Therefore, the ordering introduced by 95604873cc remains
unchanged.

This also narrows the condition for host LPI initialization from
"GICD advertises LPIs" to "a host ITS was discovered". This is
intentional: Xen currently has no supported LPI path without a host
ITS, and gicv3_lpi_init_rdist() already rejects that case with
-ENODEV. Therefore, on systems where GICD_TYPE_LPIS is set but no host
ITS is present, skipping gicv3_lpi_init_host_lpis() only avoids
allocating host LPI state that cannot be used by a supported Xen LPI
path.

Fixes: dcb6cb263689 ("ARM: GICv3 ITS: introduce host LPI array")
Fixes: 751ec850ec1d ("ARM: ITS: implement quirks and add support for
Renesas Gen4 ITS")
Signed-off-by: Mykola Kvach <mykola_kvach@xxxxxxxx>
Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx>
Reviewed-by: Michal Orzel <michal.orzel@xxxxxxx>

Cheers,
Mykola