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

[Julien Grall <julien@xxxxxxx>]

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