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

[Mykola Kvach <mykola_kvach@xxxxxxxx>]

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@xxxxxxxx>
Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx>
---
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