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

[Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>]

Hello Mykola and Julien,


On 6/21/26 5:49 PM, Mykola Kvach wrote:
> 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>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>

Thanks.

~ Oleksii