gicv3_lpi_init_host_lpis() allocates host LPI state, including the
host LPI lookup table, CPU notifier state and the boot CPU pending table.
Those allocations use gicv3_its_get_memflags().

ITS quirks are discovered by gicv3_its_init(), so allocating host LPI
state from gicv3_dist_init() can happen before the memory restrictions
required by the ITS are known. On affected systems this can leave
Redistributor LPI state allocated and programmed with 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.

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@epam.com>
Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
---
Changes in v2.5:
- Rework the commit message to explain why host LPI initialization is now
  tied to the presence of a host ITS.
- Document the intentional behavior change from checking GICD_TYPE_LPIS to
  checking whether a host ITS was discovered.
- Add Fixes tags for the host LPI allocation and ITS quirks ordering issues.
- No code changes.

Changes in v2:
- Replace the v1 ITS pre-initialization hook with the less invasive
  approach suggested during review: move the existing host LPI
  initialization after gicv3_its_init().
- Check gicv3_lpi_init_host_lpis() and panic on failure, matching the fatal
  nature of host LPI setup once ITS initialization succeeded.
---
 xen/arch/arm/gic-v3.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 17ff85ef5d..acdac22953 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -764,9 +764,6 @@ static void __init gicv3_dist_init(void)
     type = readl_relaxed(GICD + GICD_TYPER);
     nr_lines = 32 * ((type & GICD_TYPE_LINES) + 1);
 
-    if ( type & GICD_TYPE_LPIS )
-        gicv3_lpi_init_host_lpis(GICD_TYPE_ID_BITS(type));
-
     /* Only 1020 interrupts are supported */
     nr_lines = min(1020U, nr_lines);
     gicv3_info.nr_lines = nr_lines;
@@ -1990,6 +1987,17 @@ static int __init gicv3_init(void)
         res = gicv3_its_init();
         if ( res )
             panic("GICv3: ITS: initialization failed: %d\n", res);
+
+        /*
+         * Host LPI allocation uses ITS-derived memory attributes, so defer it
+         * until after gicv3_its_init() has discovered ITS workarounds.
+         */
+        if ( gicv3_its_host_has_its() )
+        {
+            res = gicv3_lpi_init_host_lpis(intid_bits);
+            if ( res )
+                panic("GICv3: LPI initialization failed: %d\n", res);
+        }
     }
 
     res = gicv3_cpu_init();
-- 
2.43.0

On 19-Jun-26 07:45, Mykola Kvach wrote:
> gicv3_lpi_init_host_lpis() allocates host LPI state, including the
> host LPI lookup table, CPU notifier state and the boot CPU pending table.
> Those allocations use gicv3_its_get_memflags().
> 
> ITS quirks are discovered by gicv3_its_init(), so allocating host LPI
> state from gicv3_dist_init() can happen before the memory restrictions
> required by the ITS are known. On affected systems this can leave
> Redistributor LPI state allocated and programmed with 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.
> 
> 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@epam.com>
> Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>

~Michal

@Oleksii, can we ask for a release ack here?

~Michal

On 19-Jun-26 08:09, Orzel, Michal wrote:
> 
> 
> On 19-Jun-26 07:45, Mykola Kvach wrote:
>> gicv3_lpi_init_host_lpis() allocates host LPI state, including the
>> host LPI lookup table, CPU notifier state and the boot CPU pending table.
>> Those allocations use gicv3_its_get_memflags().
>>
>> ITS quirks are discovered by gicv3_its_init(), so allocating host LPI
>> state from gicv3_dist_init() can happen before the memory restrictions
>> required by the ITS are known. On affected systems this can leave
>> Redistributor LPI state allocated and programmed with 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.
>>
>> 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@epam.com>
>> Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> Reviewed-by: Michal Orzel <michal.orzel@amd.com>
> 
> ~Michal
> 
>

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?

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.

Cheers,

-- 
Julien Grall

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.

> 
> 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.

~Michal

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.

Cheers,

-- 
Julien Grall

Hi Julien, Oleksii,

On Fri, Jun 19, 2026 at 2:52 PM Julien Grall <julien@xen.org> 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

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@xen.org> 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 4.22, no need to send a new patch. You could propose a new commit 
message here and we update on merge.

Cheers,

-- 
Julien Grall

Hi Julien,

Thanks.

On Fri, Jun 19, 2026 at 8:23 PM Julien Grall <julien@xen.org> 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@xen.org> 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@epam.com>
Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>

Cheers,
Mykola

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@xen.org> 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@xen.org> 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@epam.com>
> Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> Reviewed-by: Michal Orzel <michal.orzel@amd.com>
> 
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

Thanks.

~ Oleksii

On 6/19/26 1:52 PM, Julien Grall 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.

Julien, do you think that a fix should be done differently and this one 
isn't really acceptable?

~ Oleksii

On 19/06/2026 14:17, Oleksii Kurochko wrote:
> 
> 
> On 6/19/26 1:52 PM, Julien Grall 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.
> 
> Julien, do you think that a fix should be done differently and this one 
> isn't really acceptable?

The code is alright for 4.22 so long the ordering impact is clarified in 
the commit message.

But for the next release, I think it would be good to move the LPI init 
call in the ITS initialization so we can have the following steps:
  1. Query the workaround
  2. Initialize LPIs
  2. Initialize the ITSes

Cheers,

-- 
Julien Grall